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

Уязвимости в драйвере к GPU ARM, уже применяемые для совершения атак, opennews (??), 03-Окт-23, (0) [смотреть все] ох, еще не научились нормально работать с оперативной памятью, тае еще и с GPU , Аноним (1), 14:38 , 03-Окт-23, (1) // Вообще-то, Mali - это интеграшки, у которых нет отдельного чипа памяти, Аноним (13), 15:36 , 03-Окт-23, (13) +4 // я имел в виду, что такую радость уже реализовали на некоторых линейках процессо, Аноним (1), 15:43 , 03-Окт-23, (17) –1 // Это тоже самое что и Resizable BAR Нет там никакого прямого доступа к памяти, ва, мяя (?), 16:13 , 03-Окт-23, (28) +4 Ещё уточню, BAR это Base Address Registers Без Resizable BAR доступно только 25, мяя (?), 16:33 , 03-Окт-23, (35) +1 от 1МБ до 512ГБ , мяя (?), 16:33 , 03-Окт-23, (36) в реальности NVidia A100 имеет 80Gb на борту доступные через resizable BAR , Аноним (70), 19:43 , 03-Окт-23, (70) +1 ОК, моя ошибка, я почему-то записал ограничения интела на всех , мяя (?), 22:24 , 03-Окт-23, (94) BAR address physical function BAR0 16 MiB1BAR1 128 GiB1BAR3 32 MiB1BAR addr, Аноним (70), 19:46 , 03-Окт-23, (71) +1 Да я лоханулся и неглядя ляпнул , мяя (?), 22:25 , 03-Окт-23, (95) Есть и Resizable BAR, Аноним (31), 16:19 , 03-Окт-23, (31) +1 В целом прямой доступ и унифицированная память для всего памяти это далёкие м, мяя (?), 16:37 , 03-Окт-23, (38) а в чём проблема кроме того что у различных ускорителей внутреннее представление, Аноним (74), 20:01 , 03-Окт-23, (74) +1 Надо менять архитектуру ПК, в этом проблема Никто её менять особо не хочет Тех, мяя (?), 22:29 , 03-Окт-23, (96) Более конкретно сказать сложно, я не настолько специалист Насколько я знаю, там, мяя (?), 22:39 , 03-Окт-23, (97) Ну ещё мы приходим к тому что выгоднее держать память поближе к процессору, то е, мяя (?), 22:45 , 03-Окт-23, (100) про HBM тоже не слышали , Аноним (74), 23:59 , 03-Окт-23, (104) Слышали и цену видели Ну и как она, во всех домашних современных ПК стоит , мяя (?), 01:53 , 04-Окт-23, (114) неужели вы про SoC никогда не слышали там давно вся память общая для всех устр, Аноним (74), 23:57 , 03-Окт-23, (103) SoC не считается Apple silicon во многом мусор с ускорителями фотошопа и т п , мяя (?), 23:59 , 03-Окт-23, (105) +1 он как раз и считается, а концепцию эту предложил автор risc-v лет 30 назад, Аноним (74), 00:14 , 04-Окт-23, (107) SoC не расширяем, не обновляем Это уход от гибкости архитектуры ПК, а хотелось , мяя (?), 01:54 , 04-Окт-23, (115) Есть SoC с usb и даже pcie - вполне себе расширяемо вроде А современные процы о, Аноним (-), 12:05 , 05-Окт-23, (157) Я не про USB, PCIe конечно хорошо, но сама по себе концепция SoC подразумевает ч, мяя (?), 15:29 , 05-Окт-23, (173) x86 тоже сделали этот шаг, убрав скажем солидную часть чипсета в проц, так что т, Аноним (180), 16:45 , 05-Окт-23, (180) всего-то штуковина которая мощнее 775 зеонов местных обитателей вместе взятых, и, мсчмчс (?), 13:48 , 04-Окт-23, (132) На архитектуре IBM Power это уже давно сделано Оно точно уже было во времена ан, Ddddd (?), 09:41 , 04-Окт-23, (120) Скрыто модератором, Ddddd (?), 09:44 , 04-Окт-23, (121) Монолитное ядро оно такое, мелкий баг в одном из тысяч драйверов от васянопроизв, Аноньимъ (ok), 14:55 , 03-Окт-23, (2) +1 // А ты прямо сторонник цифровой тюрьмы Хочешь жить в клетке, понимаю , Аноним (5), 15:11 , 03-Окт-23, (5) –6 // Это ложная дихотомия Автор считает, что микроядро этой проблеме не подвержено В, Аноним (7), 15:17 , 03-Окт-23, (7) +5   // Не на 100 же не подвержено , Аноним (19), 15:46 , 03-Окт-23, (19)   Но это дорого стоит Много сообщений парсить надо А линукс силен именно там, гд, Иван_Лох (?), 16:28 , 03-Окт-23, (33) –1   Я думал всякие bugurtos с RT-Thread лезут туда, где байтом и тактом меньше а то, Аноним (40), 16:54 , 03-Окт-23, (40) +3   малыми усилиямиЧто тоже неплохо, и такой подход может иметь место , Аноним (40), 16:56 , 03-Окт-23, (42)   Не, это не так работает, производительность в этом всём вопрос десятый Вообще ка, Аноньимъ (ok), 17:03 , 03-Окт-23, (44) +2   Интересно, если микроядерная архитектура ядра такая классная, то почему все сидя, Анонем (?), 20:33 , 03-Окт-23, (80)   Если коротко, то ответ - Легаси Сейчас бы найти кого-то кто хоть может читать и , Аноньимъ (ok), 21:02 , 03-Окт-23, (84) +3   Ну вот ты такой инновационный - начни с себя И делом покажи чего твои блабла ст, Аноним (137), 16:07 , 04-Окт-23, (137) –1   Проблема легаси парралельна инновациям, это разные вещи Но конечно оно, легаси, , Аноньимъ (ok), 21:33 , 04-Окт-23, (150)   Ну так на чужом горбу все здоровы в рай въехать Вот обуть бы вас на легаси - и , Аноним (-), 12:10 , 05-Окт-23, (158)   Хаскель это технологии древних вообще, к инновациям отношения не имеет Я не беру, Аноньимъ (ok), 12:31 , 05-Окт-23, (161)   Это технология отшибленых на голову академов, имхо Которые и сами то ей пол, Аноним (182), 18:59 , 05-Окт-23, (182)   Вы говорите с бесами у себя в голове И не замечаете этого Так это как бы серьёз, Аноньимъ (ok), 19:45 , 05-Окт-23, (184)   Скрыто модератором, 123 (??), 10:42 , 04-Окт-23, (128) +1   Кто-то на винде сидит Винда довольно успешно перезапускает упавший драйвер видео, Аноньимъ (ok), 17:42 , 04-Окт-23, (142)   Я и заметил - вооооое там при апдейте винды интеграшка встала колом И все, что , Аноним (-), 12:12 , 05-Окт-23, (159)   Винда какая Курсор работает значит драйвер подхватился Окружение оконное сдохло, Аноньимъ (ok), 15:23 , 05-Окт-23, (171)   Это восьмая так, там походу апдейченые дрова GPU в апдейтах были Оно и изобрази, Аноним (-), 19:25 , 05-Окт-23, (183)   Угу, только потом производительность такая получается что никто это использовать, Аноним (180), 16:14 , 04-Окт-23, (138)   Да понял понял я, всё будет хорошо Шина PCI-E это у вас не барьер Ну готовит ЦП, Аноньимъ (ok), 16:59 , 04-Окт-23, (140)   Да вот не будет как показала практика Blackberry в свое время много трахались с, Аноним (-), 18:43 , 04-Окт-23, (144)   Так приложение в юзерспейсе не в ядре живёт или в ядре Небезопасно или безопасно, Аноньимъ (ok), 21:15 , 04-Окт-23, (148)   1 Приложение драйвер видяхи и как правило гигазы данных в секунду не неворач, Аноним (-), 13:46 , 05-Окт-23, (165)   В смысле не наворачивает У нас же приложения в конечном счёте видеокарту исполь, Аноньимъ (ok), 15:43 , 05-Окт-23, (175)   Оно ж не делает вообше все операции лично и микроменеджмент деталей - не юзермод, Аноним (185), 07:07 , 06-Окт-23, (185)   Я правильно понимаю вас, вы хотите сказать, что переключением видеорежимов и пр, Аноньимъ (ok), 14:18 , 06-Окт-23, (190)   Нехрена себе, а зачем делают если работает не очень Делать больше нечего людям , Аноньимъ (ok), 14:30 , 06-Окт-23, (191)   ага почти иммутабельная выделенная память для микроядра, на отдельном кернель, Sw00p aka Jerom (?), 16:29 , 03-Окт-23, (34) +1   1 Вот автору и карты в руки кодить дрова под его любимые микроядра Можно даже , Аноним (137), 16:06 , 04-Окт-23, (136) –2   ошибся веткой, так что продублирую в правильнойт е ты считаешь, что только моно, Аноним (1), 15:24 , 03-Окт-23, (10) +1 // Тут аргумент может быть такой не будет уязвимостей в Ведроиде - не будет возмож, Аноним (19), 15:48 , 03-Окт-23, (20) +1 во-первых, думаю около 98 пользователей дроида это просто нафиг не нужно они д, Аноним (1), 15:56 , 03-Окт-23, (21) Я могу ошибаться, но, похоже что требование невозможности рута идёт от Гугла, ил, Аноньимъ (ok), 17:06 , 03-Окт-23, (45) –1 не слышал о таком, насколько вижу у пикселей бутлоадер открытыйи рутуется он без, фнон (?), 17:26 , 03-Окт-23, (49) Вы мешаете рут, и разблокировку бутлоадера в одну кучу Да, разблокированный бутл, Аноньимъ (ok), 17:52 , 03-Окт-23, (54) У меня вот прям сейчас в руках анлокнутый рутованый ксяоми с LineageOS 20 0 13 , Анонин (?), 18:10 , 03-Окт-23, (57) –1 Да, нужны Считайте выиграли в лотерею А может я что-то пропустил Гпей работает , Аноньимъ (ok), 18:15 , 03-Окт-23, (58) Ну, не в лотерею Телефон сразу покупался с планом его перепрошить Т е не на ст, Анонин (?), 18:22 , 03-Окт-23, (60) –1 Ты все пропустилGoogle Pay всегда работал с рутом без проблемНа рут жаловались в, Аноним (99), 22:45 , 03-Окт-23, (99) –1 У меня жалуются иные приложения стран иных Знаю что на унлокнутых ксяомях оплата, Аноньимъ (ok), 00:14 , 04-Окт-23, (108) Мои прошлые Redmi Note 8T и Poco X3 Pro смотрят с удивлением на чушь про нерабо, Аноним (99), 10:00 , 04-Окт-23, (123) Сейчас на ксяомяу даже умные дома перестали работать У них что-то с серверами и, Аноним (-), 14:07 , 05-Окт-23, (166) Печально это всё конечно А Столлман ведь на примере секс игрушек объяснял, что , Аноньимъ (ok), 15:45 , 05-Окт-23, (176) АгаИдет значит от гугла и потому на Пикселях с рутом нет проблем, а на всяких Са, Аноним (99), 22:43 , 03-Окт-23, (98) Google Pay работает Про бета программы не знаю Хорошо вам если всё работает , Аноньимъ (ok), 00:10 , 04-Окт-23, (106) Конечно работает и всегда работалНикогда у GPay не было проблем с рутом, Аноним (99), 09:58 , 04-Окт-23, (122) А вот оставшиеся 2 есть вариант, который хоть отчасти но сдерживает жадность не, 48 (?), 02:48 , 05-Окт-23, (152) Ну так неудивительно Достаточно посмотреть где используется микроядро - OpenVMS, Анонин (?), 15:40 , 03-Окт-23, (15) +3 // Скрыто модератором, 123 (??), 10:49 , 04-Окт-23, (129) Топящему за безопасТный, безопасTный поможет , Аноним (19), 15:44 , 03-Окт-23, (18) –1 // Только если все ядро на нем было бы написано И то не на 100 помог бы Нужны бол, Анонин (?), 15:59 , 03-Окт-23, (22) та подожди, мы пока не выяснили на чем эти кода писалисьно как только выясним, м, фнон (?), 16:06 , 03-Окт-23, (24) В GPU как и к сетевым адаптерам применяется как можно меньше прослоек и провер, maxis11 (ok), 21:17 , 03-Окт-23, (90) +1 // О Уважаемый, как прекрасно что есть грамотные люди будь другом, научи - как п, Аноним333 (?), 21:46 , 03-Окт-23, (92) Очень мощная техническая бурда Так просто не осилить, нужна команда сишников чт, Аноньимъ (ok), 22:16 , 03-Окт-23, (93) // Самое ужасное, что дьявол кроется в деталях Рассмотрим CVE-2023-4211 если коро, maxis11 (ok), 23:38 , 03-Окт-23, (102) +1 Прошивка ВК работает на ЦП системы Не знал Оно одинаково и на виндовсе и линукс, Аноньимъ (ok), 00:34 , 04-Окт-23, (112) Там хуже все, в GPU есть микруха, которая управляет этим самым устройством в Po, maxis11 (ok), 01:13 , 04-Окт-23, (113) +2 Очень круто, спасибо за сообщения , мяя (?), 18:50 , 04-Окт-23, (145) Это не микруха а IP-блок и сервисный процессор Это все очень от производител, Аноним (-), 14:12 , 05-Окт-23, (167) Спасибо за подробный ответ, было познавательно 1 Не знаешь ли насколько очень , Аноним (1), 10:42 , 04-Окт-23, (127) У ARM вроде не настолько продвинутые GPU чтоб свой MMU еще был, это вам не амдшк, Аноним (-), 18:32 , 04-Окт-23, (143) Грубо говоря основная фича в другой модели доступа к памяти, остальное детали ЦП, Аноньимъ (ok), 21:26 , 04-Окт-23, (149) Вообще-то в случае ARM и интеграшек о которых мы тут - оно как раз вынуждено дел, Аноним (-), 15:41 , 05-Окт-23, (174) Я не работал с амд на уровне допиливания прошивки только на уровне драйвера , н, maxis11 (ok), 02:47 , 05-Окт-23, (151) Поправка тайлинг и пастеризация это одно и тоже лень авторизироваться , Аноним (153), 04:53 , 05-Окт-23, (153) А тут в топике про ARMовские дизайны, у них я вообще сервисных ядер так сразу не, Аноним (-), 16:31 , 05-Окт-23, (178) а че вы ожидали от ЧатГопоты софт-скилы ептить , Sw00p aka Jerom (?), 00:33 , 04-Окт-23, (111) И дайте угадаю, старые устройства обновить практически нереально Enjoy , Аноним (6), 15:13 , 03-Окт-23, (6) +4 // Enjoy the monolithic Linux kernel with unstable API ABI which requires constant , birdie (ok), 15:19 , 03-Окт-23, (8) –4 // Причём здесь unstable ABI в ядре, если ведроидные драйвера работают в юзерспейсе, Аноним (19), 16:09 , 03-Окт-23, (27) // а вот здесь сказано, что нетhttps source android com docs core architecture ke, Аноним (43), 16:57 , 03-Окт-23, (43) Что вы несёте я не могу понять Там такое же ядро, только хуже - полный монолит , birdie (ok), 03:28 , 04-Окт-23, (116) угу, скорее всего так и будета то что обновления андроида зависит еще и от вендо, Аноним (1), 15:29 , 03-Окт-23, (11) +3 // предлагаю погуглить среднюю цену строчки кода и цену строчки кода в se4L, RM (ok), 12:49 , 04-Окт-23, (131) Ну так Настало время покупать новые устройсва Все по плану же Вспомните ско, Kuromi (ok), 15:35 , 03-Окт-23, (12) –1 Линукс поделие во всей красе , Аноним (14), 15:39 , 03-Окт-23, (14) // Вангую, что телефоны на Фикции, если такие появятся, поддерживаться обновлениями, Аноним (19), 16:07 , 03-Окт-23, (25) // СомневаюсьГугл тут соперничает с эплом, и приходится делать не хуже чем у конку, фнон (?), 16:18 , 03-Окт-23, (30) +1 А продажи обратно пропорцианальны длительности поддержки , Аноним (19), 16:21 , 03-Окт-23, (32) Вот только никто никогда не планировал никаких телефонов на Фуксии а Фикция это , Аноним (99), 22:46 , 03-Окт-23, (101) Рукожопы ARM, а виноват как всегда линукс, uis (??), 20:17 , 03-Окт-23, (77) // да 128070 концепция линукса, изначально ошибочная и ущербная no discussion , Аноним (81), 20:37 , 03-Окт-23, (81) Вот и хорошо, можно получить рута или даже получать рута каждый раз, когда это , YetAnotherOnanym (ok), 20:07 , 03-Окт-23, (76) Проблема наблюдается в Pixel 7 и его ровесниках, а ты про старые телефоны не об, Аноним (99), 10:02 , 04-Окт-23, (124) Ах вот почему хейтеры Сишки молчат в тряпочку Уязвимости оказались в проприетар, Аноним (-), 17:25 , 03-Окт-23, (48) –2 // которые тоже были написаны на сишечке , Анонин (?), 17:34 , 03-Окт-23, (50) +1 // сорян, на расте такое не пишут опенсорсное тоже, Аноним (53), 17:45 , 03-Окт-23, (53) +1 // хаха, гугл который часть андроида пишет на раст как раз по причине подобных mem, Аноним (1), 18:07 , 03-Окт-23, (55) –2 а какое отношение открытость закрытость, вид лицензии и т д влияют на язык прил, Аноним (1), 17:43 , 03-Окт-23, (51) // Если язык такое не позволяет, то такой язык нахер не годится для написания ОС , Аноним (109), 00:24 , 04-Окт-23, (109) –2 ARM это телефонный мусор Пора бы некоторым товарищам понять это, что единственн, Аноним (-), 20:07 , 03-Окт-23, (75) –1 // ARM это еще и одноплатники, яблобуки, ябломини - в общем не всегда совсем тощая , Аноним (169), 15:18 , 05-Окт-23, (169) –1 // А еще 1 Нету открытого компилера по сути 2 Все изменения кишок немедленно от, Аноним (180), 16:39 , 05-Окт-23, (179) +1 Надо было ставить что Lima , uis (??), 20:21 , 03-Окт-23, (78) // Или Panfrost, uis (??), 20:24 , 03-Окт-23, (79) +1 Раз уж речь зашла о Си, то недавно обнаружил весьма люботный факт, - может кто-н, Аноним (82), 20:41 , 03-Окт-23, (82) // Дремучее легаси потому что , Анонимусс (?), 21:00 , 03-Окт-23, (83) –1 Напиши свою fgets , Аноним (109), 00:27 , 04-Окт-23, (110) Стандартный ввод вывод в Си 8212 это хтонический ужас Собственно, он во всех, Аноним (119), 08:53 , 04-Окт-23, (119) +1 // Скрыто модератором, Аноним (-), 16:30 , 05-Окт-23, (177) Да не только И О, а все строковые утилиты Все что мне были нужны я переписал по, InuYasha (??), 18:52 , 05-Окт-23, (181) Какие создатели и чего именно The fgets function reads at most one less than the, Аноним (130), 11:52 , 04-Окт-23, (130) // Т е вы считаете, что если пользователь получает бесконечный цикл, при n равным е, Аноним (82), 15:18 , 04-Окт-23, (133) // Я не вижу ни цикла в вышеприведённом коде, ни требований в стандарте зацикливать, Аноним (130), 15:34 , 04-Окт-23, (135) Смысл в том что, скорее всего вы будете использовать fgets таким образом while , Аноним (82), 16:55 , 04-Окт-23, (139) ПС для наглядной иллюстрации для простоты просто возьмите статический массив ра, Аноним (82), 17:02 , 04-Окт-23, (141) Ну, как-бы, Вы сами функцию зациклили Аналогичное поведение будет, если Вы укаж, Совершенно другой аноним (?), 12:31 , 05-Окт-23, (160) +1 Показательный пример, кстати Если fgets заменить на true - тогда виновата во вс, Аноним (130), 13:19 , 05-Окт-23, (163) +1 Моя претензия в том, что о такой дичи нужно писать в документации, как это сдела, Аноним (82), 15:15 , 05-Окт-23, (168) Честно говоря, за около 20-ти летний опыт использования языка С, как-то ниразу н, Совершенно другой аноним (?), 08:41 , 06-Окт-23, (187) Я сам был мягко говоря удивлён Проблема в том, что там использовался динамическ, Аноним (82), 10:13 , 06-Окт-23, (188) В том плане - фунция fgets ожидает буфер, имеющий возможность хранить как мини, Совершенно другой аноним (?), 13:23 , 05-Окт-23, (164) что потомки будут хотеть, по факту, ввести 0 символов Дьявол кроется в деталях , Аноним (82), 10:29 , 06-Окт-23, (189) Не буду Случилось 1 выдумывание глупости 2 приписывание её оппоненту 3 ненавя, Аноним (130), 13:07 , 05-Окт-23, (162) +1 Да я и сам выкинул это гумно на помойку и написал свою версию c нормальным API, , Аноним (82), 15:20 , 05-Окт-23, (170) это не моя глупость , а реальность с которой мне пришлось недавно столкнуться в, Аноним (82), 15:24 , 05-Окт-23, (172) Спасибо, что раскрыли сведения Теперь эти уязвимости будут юзать все кому не ле, ИмяХ (?), 21:05 , 03-Окт-23, (85) Прилаги из гугл плей тоже могут И БУДУТ Думаете им достаточно будет разрешения , Пряник (?), 10:15 , 04-Окт-23, (125) // откуда блок заранее знает, где конкретно находится какая вышка или вайфай-раздач, Бывалый смузихлёб (?), 09:16 , 05-Окт-23, (154) // Гугл собирает базу данных со инфой о всех вышках и точках вай фай незаметно для, Пряник (?), 10:07 , 05-Окт-23, (155) Регулярно пишут про уязвимости в андроиде Но почему-то не слышно про вирусы, ко, nymous (?), 15:31 , 04-Окт-23, (134) // Дай угадаю, ты живёшь в стране эльфов и в ней в салонах связи не продают телефон, Аноним (-), 18:56 , 04-Окт-23, (146) +1 // Адварь в прошивке, заботливо приготовленная производителем - это одно А вирус, к, nymous (?), 11:05 , 05-Окт-23, (156) // Там еще спайварь есть, сливающая все вплоть до паролей на точки доступа, и малва, Аноним (-), 07:55 , 06-Окт-23, (186) –1 А вам не кажется, что все эти уязвимости нацелены лишь на то, чтобы плебс прио, Бульдох (?), 20:31 , 04-Окт-23, (147) –1 // Вера в теорию заговора - признак психической болезниСходи ко врачу, Аноним (99), 21:22 , 06-Окт-23, (192) 1,2,6,48,75,78,82,85,125,134,147

Сообщения

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

	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
	Кто эти "все", они в одной с вами комнате? BSD, NT, XNU/Darwin, Solaris не монолит.
	Ответить | Правка | К родителю #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ообщить модератору

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

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