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

"Уязвимости в драйвере к GPU ARM, уже применяемые для совершения атак"	+/–
Сообщение от opennews (??), 03-Окт-23, 14:38
Компания ARM раскрыла сведения о трёх уязвимостях в  драйверах для своих GPU, используемых в Android, ChromeOS и дистрибутивах Linux. Уязвимости позволяют непривилегированному локальному  пользователю выполнить свой код с правами ядра. В октябрьском отчёте о проблемах с безопасностью в платформе Android упоминается, что до появления исправления  одна из уязвимостей (CVE-2023-4211) уже задействована злоумышленниками в  рабочих эксплоитах для совершения целевых атак (0-day). Например, уязвимость может применяться в распространяемых через сомнительные источники вредоносных приложениях для получения полного доступа к системе и установки компонентов, шпионящих за пользователем... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59860
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
Сообщение от Аноним (1), 03-Окт-23, 14:38
ох, еще не научились нормально работать с  оперативной памятью, тае еще и с GPU то же самое /_- а еще хотят чтобы память cpu/gpu была общая > выполнение некорректной операции с памятью > переполнению буфера и получению доступа к памяти за пределами выделенного буфера
Ответить | Правка | Наверх | Cообщить модератору

	13. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+4 +/–
	Сообщение от Аноним (13), 03-Окт-23, 15:36
	>а еще хотят чтобы память cpu/gpu была общая Вообще-то, Mali - это интеграшки, у которых нет отдельного чипа памяти
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–1 +/–
	Сообщение от Аноним (1), 03-Окт-23, 15:43
	я имел в виду, что такую радость уже реализовали (на некоторых линейках процессоров) в десктопах типа AMD Smart Access Memory (которая работает и на некоторых интелах) когда идет прямой доступ процессора к видеопамяти
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+4 +/–
	Сообщение от мяя (?), 03-Окт-23, 16:13
	> типа AMD Smart Access Memory (которая работает и на некоторых интелах) Это тоже самое что и Resizable BAR. > когда идет прямой доступ процессора к видеопамяти Нет там никакого прямого доступа к памяти, вас обманули. Просто теперь сняты ограничения на доступный объём памяти. В остальном всё как и прежде, сначала идёт пересылка в оперативную память (зарезервированный буффер), а потом из оперативной памяти поэтапно через все кэши процессора.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от мяя (?), 03-Окт-23, 16:33
	Ещё уточню, BAR это Base Address Registers. Без Resizable BAR доступно только 256МБ видеопамяти за раз, с ним уже можно произвольно адресовать (MMIO space) от 1ГБ до 512ГБ (сферически, в реальности пока до 64ГБ) видеопамяти. Бонус: https://github.com/xCuri0/ReBarUEFI >  A UEFI DXE driver to enable Resizable BAR on systems which don't support it officially. This provides performance benefits and is even required for Intel Arc GPUs to function optimally.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мяя (?), 03-Окт-23, 16:33
	*от 1МБ до 512ГБ
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Аноним (70), 03-Окт-23, 19:43
	в реальности NVidia A100 имеет 80Gb на борту доступные через resizable BAR.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

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

	71. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Аноним (70), 03-Окт-23, 19:46
	BAR address (physical function) BAR0: 16 MiB1 BAR1: 128 GiB1 BAR3: 32 MiB1 BAR address (virtual function) BAR0: 5 MiB, (256 KiB per VF)1 BAR1: 80 GiB, 64-bit (4 GiB per VF)1 BAR3: 640 MiB, 64-bit (32 MiB per VF)1 https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Cent...
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

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

	31. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Аноним (31), 03-Окт-23, 16:19
	Есть и Resizable BAR
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	38. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мяя (?), 03-Окт-23, 16:37
	В целом прямой доступ (и унифицированная память для всего) памяти это "далёкие мечты", этого крашком можно увидеть на некоторых приставках и то ограничено.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	74. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Аноним (74), 03-Окт-23, 20:01
	> В целом прямой доступ (и унифицированная память для всего) памяти это "далёкие мечты" а в чём проблема кроме того что у различных ускорителей внутреннее представление данных в буферах тайловое ?
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мяя (?), 03-Окт-23, 22:29
	Надо менять архитектуру ПК, в этом проблема. Никто её менять особо не хочет. Технически это решаемо, но никто не идёт на такой шаг, желания у людей сверху нет. Видимо пока не начнём совсем упираться они не будут менять подходы.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мяя (?), 03-Окт-23, 22:39
	Более конкретно сказать сложно, я не настолько специалист. Насколько я знаю, там тянутся и проблемы с различием тактовых частот, проблемы синхронизации, ну и в целом разводка. Есть и экономические/бизнес причины. Это они должны договориться как ЦП будет работать с ГП. Нужно как минимум менять подходы что оперативная память становится не основной памятью, вряд ли же захотят лишаться дешёвой DDR памяти в угоду одной GDDR дорогой!? Даже в консолях и то всё равно поставили дешёвую DDR чтобы система не кушала дорогую память зазря. Дальше у нас много вариантов как мы могли бы организовать новую архитектуру... По идее тузы в руках у тех кто имеет производство и ГП и ЦП, но пока ни один производитель не делает серьёзных шагов к этому.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мяя (?), 03-Окт-23, 22:45
	Ну ещё мы приходим к тому что выгоднее держать память поближе к процессору, то есть мы начинаем конфликтовать ГП с ЦП за это. Получается у нас есть проблемы в том как мы должны компоновать. Это решаемо конечно, но без компромиссов не получится. Кстати видеокарты сейчас отучают от зависимости ЦП https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre.../ Для вулкана такое пока только у AMD есть https://gpuopen.com/gpu-work-graphs-in-vulkan/
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (74), 03-Окт-23, 23:59
	> вряд ли же захотят лишаться дешёвой DDR памяти в угоду одной GDDR дорогой!? про HBM тоже не слышали ?
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	114. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мяя (?), 04-Окт-23, 01:53
	Слышали и цену видели. Ну и как она, во всех домашних современных ПК стоит?
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (74), 03-Окт-23, 23:57
	> Надо менять архитектуру ПК, в этом проблема. Никто её менять особо не хочет. неужели вы про SoC никогда не слышали ? там давно вся память общая для всех устройств, Apple silicon из того что помощней.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	105. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от мяя (?), 03-Окт-23, 23:59
	SoC не считается. Apple silicon во многом мусор с ускорителями фотошопа и т.п.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (74), 04-Окт-23, 00:14
	> SoC не считается. он как раз и считается, а концепцию эту предложил автор risc-v лет 30 назад
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мяя (?), 04-Окт-23, 01:54
	SoC не расширяем, не обновляем. Это уход от гибкости архитектуры ПК, а хотелось бы гибкость на каком-то уровен сохранить.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (-), 05-Окт-23, 12:05
	> SoC не расширяем, не обновляем. Это уход от гибкости архитектуры ПК, а > хотелось бы гибкость на каком-то уровен сохранить. Есть SoC с usb и даже pcie - вполне себе расширяемо вроде. А современные процы от SoC недалеко ушли, в 1 кристалле куча хлама, вплоть до ME или PSP всяких. И деление довольно условное в результате.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мяя (?), 05-Окт-23, 15:29
	>> SoC не расширяем, не обновляем. Это уход от гибкости архитектуры ПК, а >> хотелось бы гибкость на каком-то уровен сохранить. > Есть SoC с usb и даже pcie - вполне себе расширяемо вроде. > А современные процы от SoC недалеко ушли, в 1 кристалле куча > хлама, вплоть до ME или PSP всяких. И деление довольно условное > в результате. Я не про USB, PCIe конечно хорошо, но сама по себе концепция SoC подразумевает что всё важное у нас будет на одном чипе. В случае с текущей архитектурой у нас отдельно ЦП, отдельно оперативная память, некоторые штуки на материнке и зачастую отдельно видеоускоритель. Понятно что сейчас в процессор пихают много всего, но всё ещё некоторая гибкость сохраняется.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (180), 05-Окт-23, 16:45
	> Я не про USB, PCIe конечно хорошо, но сама по себе концепция > SoC подразумевает что всё важное у нас будет на одном чипе. x86 тоже сделали этот шаг, убрав скажем солидную часть чипсета в проц, так что теперь допустим контроллер памяти - именно в проце. И это кстати по ряду причин удобнее бывает. А альтернативные чипсеты MFRы не очень то и жаловали изначально и по сути удушули это дело. > В случае с текущей архитектурой у нас отдельно ЦП, отдельно оперативная память, SoC обычно как-то так же. > некоторые штуки на материнке и зачастую отдельно видеоускоритель. К ряду SoC можно на их PCIe точно так же dGPU прицепить. Вот прямо тот же, AMDGPU плевать - на x86 работать или на ARM/RISCV/что там у вас с PCIe. В случае нвидии - ну там на что блобммейкер раздуплится, это уж извините. > Понятно что сейчас в процессор пихают много всего, но всё ещё некоторая > гибкость сохраняется. SoC понятие растяжимое. Вон там на RISCV платы с PCIe есть. Куда видяху можно воткнуть, ога.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мсчмчс (?), 04-Окт-23, 13:48
	всего-то штуковина которая мощнее 775 зеонов местных обитателей вместе взятых, и которая работает 13 часов от батарейки.
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	120. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Ddddd (?), 04-Окт-23, 09:41
	На архитектуре IBM Power это уже давно сделано. Оно точно уже было во времена анонса архитектуры NVidia GPU Turing. Учи мат.часть.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	121. Скрыто модератором	+/–
	Сообщение от Ddddd (?), 04-Окт-23, 09:44
	Вот тут - https://www.redbooks.ibm.com/redpapers/pdfs/redp5494.pdf Искать - direct system memory access
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

2. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
Сообщение от Аноньимъ (ok), 03-Окт-23, 14:55
Монолитное ядро оно такое, мелкий баг в одном из тысяч драйверов от васянопроизволителей вроде нвидии и арм, и получаешь полный доступ к ядру.
Ответить | Правка | Наверх | Cообщить модератору

	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
	Кто эти "все", они в одной с вами комнате? 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ообщить модератору

	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ообщить модератору

	15. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+3 +/–
	Сообщение от Анонин (?), 03-Окт-23, 15:40
	Ну так неудивительно. Достаточно посмотреть где используется микроядро - OpenVMS, QNX, MINIX, частично макось. А где используеьтся монолит - линукс, винда. Т.е. стабильность и надежность VS быдлокодинг и х-к, х-к и в продакшн. Так и живем((
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	129. Скрыто модератором	+/–
	Сообщение от 123 (??), 04-Окт-23, 10:49
	NT - гибридное.
	Ответить | Правка | Наверх | Cообщить модератору

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

	22. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Анонин (?), 03-Окт-23, 15:59
	Только если все ядро на нем было бы написано. И то не на 100% помог бы. Нужны более крутые меры, типа верификации. Напр. верифицировать все unsafe часть.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от фнон (?), 03-Окт-23, 16:06
	та подожди, мы пока не выяснили на чем эти кода писались но как только выясним, можно про дыряшку и написать))
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	90. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от maxis11 (ok), 03-Окт-23, 21:17
	В GPU (как и к сетевым адаптерам) применяется как можно меньше прослоек и проверок по доступу памяти к/из устройства дабы это все работало максимально быстро. Это косвенно можно проверить по: 1. в спеках OGL/Vulkan для части функций написано, что при неправильном их использовании(привет indirect) ОС может начать неправильно работать; 2. DRM подсистема чаще других использует DMA-API (тот же Prime, например). Почему это так нужно? Если развернуть графический стек (от запуска цикла отрисовки до вывода картинки на экран), то получается, что display controller (если мы говорим про Mali или PowerVR, то dc является отдельным блоком) должен выделять фреймбуферы (обычно используется двойная буферизация), чтобы передать их в блок GPU. У DC, как и у GPU может быть своя модель памяти (на PCI или нет, используется ли отдельный блок IOMMU или CMA и.т.д.) В свою очередь GPU сам создает кучу различной памяти внутри себя(открой графический конвейер и глянь сам) как и для взаимодействия с CPU (оно все работает асинхронно, простым mmap'ом и остановкой устройства для тоже синхронизации дело не сделаешь). Про когерентность кэшей я даже не хочу говорить. И вот этот весь стек я написал для одного приложения (и одного видео-выхода). А графических приложений (все современные DE используют аппаратное ускорение) может быть много (для этого и придумали DC, чтобы он аппаратно все blit'ил), все должны выводиться 60 фпс+ в 4k, а GPU вообще может виртуализироваться между несколькими гостевыми ОС. Мой посыл в этом всем: Васян — это ты; если тебе страшно жить в этом графическом мире, то выкинь ускоритель, так как он будет либо очень медленно работать, но "безопасно", либо в стеке постоянно будут находить дыры; комментаторам из опеннета советую учить мат часть.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	92. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним333 (?), 03-Окт-23, 21:46
	О! Уважаемый, как прекрасно что есть грамотные люди! будь другом, научи! - как познать всё то, что ты здесь описал (я реально 95% терминов таких не знаю!)? Можешь, гайд какой-то составить? или ссылку дать на такой, если он уже существует? ЗЫ Да, и откуда ты всё ЭТО знаешь?
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноньимъ (ok), 03-Окт-23, 22:16
	Очень мощная техническая бурда. Так просто не осилить, нужна команда сишников чтобы разобраться. Есть разные железки в мире графики. Но основной сути на самом деле это не меняет, поэтому будет PCI-e видеокарта в вакууме и ЦП в вакууме. Есть память ЦП. Есть память ВК. ЦП по шине отправляет ВК команды и данные (шейдеры текстуры и вершины в основном) Как они это делают принципиально не так то важно, ДМА там или хренуа. Так вот, ядру ОС вообще в этом всём никакой другой роли кроме медиатора не положено. Потому что выводить что-то на экран нужно окружению и программам, которые долбят драйвер, который всё это счастье отсылает в видеокарту. Заметьте, в обычном линуксе, ошибка в программе использующей вулкан опенжл или что там у вас, не приводит к доступу к памяти ядра, то есть тут как бы мы считаем по умолчанию разграничение уже есть?
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	102. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от maxis11 (ok), 03-Окт-23, 23:38
	Самое ужасное, что дьявол кроется в деталях. Рассмотрим CVE-2023-4211: если коротко, то CPU(OS) посылает команду, которая просит в вершинный конвейер запихнуть удаленные данные (можешь попробовать отправить мусорный indirect или bindless текстуры и увидеть синий экран смерти/ring timeout с последующим reset'ом/и.т.д.) Скорее всего в прошивки происходит page fault и его MMU выдает bus-адрес куда-то куда не следует выдавать, ядро это преобразовывает в виртуальный адрес и это все выдается пользователю. Потому что GPU работает в своей ОС — прошивка, которая работает на микрухе (можешь поизучать atombios, а не демагогию устраивать) со своей памятью и управление ей, управление питанием устройства, запуском кастомного кода из user-space'а (те самые шейдеры в виде IR) и.т.д. Все это дело прокидывается ей из GPU в пространстве ядра (хоть не в пространстве Intel ME/ ARM TrustZone уже хорошо). Поэтому, чтобы исправлять уязвимости, нужно исправлять все возможное неправильное поведение команд из user-space в kernel-space, так как дальше идет черный ящик, который имеет доступ к многим вещам и никак это особо не поправишь. В микроядерных ос, что я знаю, идет серьезная потеря перфы и повышенное энергопотребление из-за этого самого "ДМА там или хренуа", никуда от этого не деться. Так вот, главный смысл графического ускорителя, чтобы никакой "потери перфы" не было, как и то, чтобы у тебя рука не расплавилась держа смартфон.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноньимъ (ok), 04-Окт-23, 00:34
	Прошивка ВК работает на ЦП системы? Не знал. Оно одинаково и на виндовсе и линуксе? Просто сложно себе всё это представляю, в нюансах не разбираюсь. Мне казалось там у PCI-E довольно стандартный протокол со стандартными фичами, и в общем случае каких-то блобов на стороне ЦП ненужно.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+2 +/–
	Сообщение от maxis11 (ok), 04-Окт-23, 01:13
	Там хуже все, в GPU есть микруха, которая управляет этим самым устройством (в PowerVR это mips, meta и недавно risc-v завезли). На нем запускается прошивка, которая по сути является микро-rtos. Помимо загрузки самой прошивки ещё и передается куча памяти, которая она сама внутри будет управлять (это все на уровне ядра). PCI-e является шиной(да, я кэп) она изоляцию делает на уровне примерно никакой. DMA нужно, чтобы синхронизировать память устройства с RAM памятью (про P2PDMA не говорю). В общем случае у тебя запускается на микрухе блоб, которая находится в PCI-e (в случае дискретной карты), прокидывается туда память (то есть там микруха, которая читает и записывает в/из RAM), и она сама себе работает. Раз уж пошла такая пьянка, то вот ещё история из моего GPU-драйверописания. В случае с закрытым драйвером все ещё хуже (а насколько понял из новости это именно он). Так как они в линуксах не могут использовать большинство API из-за GPL, то обычно они вообще пилят все свою инфраструктуру вместо использования готового (свои аллокаторы, кучи, синхронизации, и.т.д.), склеивают как-то с линуксовым ядром и выносят большую часть функционала в user-space библиотеки (дабы не делиться исходниками). Это все выглядит примерно так: вместо x + y, в программе вызывается ioctl с инициализацией x и y, которое идет в ядро. Модуль ядра берет свой написанный аллокатор поверх alloc_pages возвращает какие-то дескрипторы в структуру (в моем случае ImgTec полностью соблюдали венгерскую аннотацию, из-за чего любое название выглядело как записи чернокнижников). После этого в user-space происходит какая-то проверка и вызывается ioctl с "вызывать операцию для операторов", где ядро уже складывает x + y и возвращает сумму в x. После чего вызывается ioctl для синхронизации x, y. И в ядерном модуле вызывается уже самописные memory barrier'ы на ассемблере (спрятанные по десятком макросов). Потом программа просит ядро экспортировать хэндл x (тоже через ioctl), и наконец выводит сумму. О качестве кода такого драйвера можно догадаться (зато в стиле микроядра).
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от мяя (?), 04-Окт-23, 18:50
	Очень круто, спасибо за сообщения.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (-), 05-Окт-23, 14:12
	> Там хуже все, в GPU есть микруха, которая управляет этим самым устройством Это не микруха а "IP-блок" и "сервисный процессор". > (в PowerVR это mips, meta и недавно risc-v завезли). На нем запускается прошивка, > которая по сути является микро-rtos. Это все очень от производителя зависит что там и у кого. > Помимо загрузки самой прошивки ещё и передается куча памяти, которая она > сама внутри будет управлять (это все на уровне ядра). Это не на уровне ядра. Это на уровне - железки. У того проца свое адресное пространство. Оно вообще может быть никак не видно хосту. Однако технически он может в принципе и хосту попытаться укатать, скажем DMA запросом, в ресурсы железки доступ же есть - значит и DMA какое зарядить могет в ряде случаев. В MALI может и не могет, не настолько продвинутое. А так - помнится приставки как раз и вынесли через шейдеры, провоцирующие доступ в RAM со стороны GPU который патчит слегонца high-secure DRMленую бяку. И вот она уже беззубая. > PCI-e является шиной(да, я кэп) она изоляцию делает на уровне примерно никакой. > DMA нужно, чтобы синхронизировать память устройства с RAM памятью (про P2PDMA > не говорю). В общем случае у тебя запускается на микрухе блоб, которая находится в PCI-e Это все точно про ARM GPU? :D > все свою инфраструктуру вместо использования готового (свои аллокаторы, кучи, синхронизации, > и.т.д.), склеивают как-то с линуксовым ядром и выносят большую часть функционала > в user-space библиотеки (дабы не делиться исходниками). Ну вот фирма ARM довы...сь наконец. Правда вы тут прогнали основательно но вот этот кусок верный.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	127. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (1), 04-Окт-23, 10:42
	Спасибо за подробный ответ, было познавательно! 1. Не знаешь ли насколько "очень медленно работать" будет если добавить проверки? Ну т.е. если все экраны телефонов будут вместо 60 показывать 30 кадров (или даже 20), то я бы это пережил. А если 2 кадра, то нет) 2. Правильно ли я понимаю, что rtos в управлении видяхой - это черный ящик и неизвестно даже какая там система? Может где-то что-то утекало или ломалось? 3. На проприетарных системах проблем меньше, тк они не боятся блобов, не повязаны GPL и им не приходится делать костыли чтобы слепить все вместе? Или у них все так же плохо?
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	143. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (-), 04-Окт-23, 18:32
	> экран смерти/ring timeout с последующим reset'ом/и.т.д.) Скорее всего в прошивки происходит > page fault и его MMU выдает bus-адрес куда-то куда не следует У ARM вроде не настолько продвинутые GPU чтоб свой MMU еще был, это вам не амдшка. > пользователю. Потому что GPU работает в своей ОС — прошивка, которая > работает на микрухе (можешь поизучать atombios, 1) Atombios выполняется интерпретером на стороне драйвера, внезапно. GPU рассказывает как с ним работать таким странным способом. 2) У ARM ничего подобного вроде бы нет. Там достаточно тупенькие считалки. > нужно исправлять все возможное неправильное поведение команд из user-space в kernel-space, > так как дальше идет черный ящик, который имеет доступ к многим > вещам и никак это особо не поправишь. Но вот то что GPU особенно в больших системах могут DMA вкатить - таки могут, и единственное что их на этом пути может застопорить это IOMMU так то. Да, в принципе может быть 3 разные MMU: 1) CPU-side, это тот который права доступа CPU <-> RAM энфорсит. 2) GPU-side, то же самое но со стороны GPU. ARM вроде не настолько крутые пока, а вот у амдшек есть. 3) IOMMU, этот арбитрирует доступ железок <-> RAM. Так что отфонарный DMA pcie устройства какого в левый RAM будет зарублен с треском. > вот, главный смысл графического ускорителя, чтобы никакой "потери перфы" не было, > как и то, чтобы у тебя рука не расплавилась держа смартфон. Основная фича ускорителя в основном куча SIMD-образных крушилок. Если системный проц так сделать, он будет печален на задачах общего назначения. Приходится в отдельный специализированный выносить.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	149. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноньимъ (ok), 04-Окт-23, 21:26
	> Основная фича ускорителя в основном куча SIMD-образных крушилок Грубо говоря основная фича в другой модели доступа к памяти, остальное детали. ЦП оптимизирован под случайный доступ, ГП под большие однообразные куски. В принципе с АПУ неплохо стало получаться последнее время, но там фактически две разные модели доступа на уровне контроллера ОЗУ разделяемые. Как-то это совместить идея неплохая, передавая доступ от ЦП к ГП и обратно, но сильно зависит от платформы... Сони в своих консолях вообще неплохо сделала, было бы прикольно увидеть такое на стероидах в десктопах. Но пока только в серверных решениях есть.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (-), 05-Окт-23, 15:41
	>> Основная фича ускорителя в основном куча SIMD-образных крушилок > Грубо говоря основная фича в другой модели доступа к памяти, остальное детали. Вообще-то в случае ARM и интеграшек о которых мы тут - оно как раз вынуждено делить память и шину на двоих с системным процом. И таки то что обычный DDR оптимизирован на вот именно то - не оптимально для GPU, зато так имлементация системы дешевле. И остается только мой пойнт - про массовый SIMD оптом. Круто, да? > ЦП оптимизирован под случайный доступ, ГП под большие однообразные куски. Да вот видите ли ARMовским GPU и прочим интеграхам приходится довольствоваться обычным системным DDRом как раз, оптимизированным на обычные процы. GDDR ему был бы лучше но кто ж ему его даст. Это верно только для дискреток с отдельной VRAM на отдельной шине. И конечно это сильно оптимальнее, поэтому дискретки и мощнее при прочих равных в разы, отдельная шина с отдельным бандвизом и оптимизацией на вон тот доступ. Но это денег стоит, чудес не бывает. А HBM на интерпозере еще круче. И еще дороже, ага. Делать "печатку" из кремния не дешево. > В принципе с АПУ неплохо стало получаться последнее время, но там фактически две > разные модели доступа на уровне контроллера ОЗУ разделяемые. GPU намноооооооого более массовый SIMD чем системный проц. У него число операций за такт куда как больше, особенно в топовых штуках. > Как-то это совместить идея неплохая, передавая доступ от ЦП к ГП и > обратно, но сильно зависит от платформы... Если это про шаринг памяти, у амд по своему эффектный фокус с zerocopy CPU <-> GPU есть на APU (интеграшках) дающий бонус относительно дискреток на PCIe. Но на фоне обычного DDR RAM на всю парочку вместо GDDR или HBM у GPU это все ни о чем. Вон то тоже не совсем безопасный фокус потому что маппинг 2 адресных пространств друг в друга и ессно под контролем софта, кто ж еще знает где там какие текстуры и проч и сколько этого надо в граммах. И лажа в тех маппингах конечно же достаточно чревата. > Сони в своих консолях вообще неплохо сделала, было бы прикольно увидеть такое > на стероидах в десктопах. А у них там что-то особенное было? Там вроде GPU по сути радеон обычный. > Но пока только в серверных решениях есть. Что есть? Я пока самое мощное что видел это HBM память для GPU - и в десктопных было тоже. Разгоняет вон то, под крупные блоки, дофига, с 4096-битной то шиной, но - дорогое, и сильно не подешевеет. А для SoC соответственно избыточное очень.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от maxis11 (ok), 05-Окт-23, 02:47
	> У ARM вроде не настолько продвинутые GPU чтоб свой MMU еще был, это вам не амдшка. Я не работал с амд на уровне допиливания прошивки (только на уровне драйвера), но сейчас занимаюсь этим для PowerVR. Именно в самой прошивки и создаются различные кучи инстансов устройства (к счастью без виртуализации она всего одна) и MMU там нужен для наложения всего этого. Предположил, что Mali +- одного класса устройства как PowerVR блоки, поэтому предположил, что и в прошивки это все реализовано. Сейчас зашел в реализацию panfrost и там действительно mmu на уровне драйвера работает (CPU), был не прав (ARM, получается, не осилили?) > 1) Atombios выполняется интерпретером на стороне драйвера, внезапно. GPU рассказывает как с ним работать таким странным способом. atombios взял, потому что: у них довольная солидная таблица команд, для управления микрухи (ну и прошивки которая крутится на ней) и по коду становится понятно, что там отдельный управляющий блок с отдельной rtos. В PowerVR там проще: настройка pagetable'ов как раз для MMU (по факту pool dma памяти передается по регистрам), наложение прошивки на heap устройства и, собственно, отправка адреса на начало boot секции в регистр. После этого GPU запущено. > 2) У ARM ничего подобного вроде бы нет. Там достаточно тупенькие считалки. Написал, что был не прав. Но вообще, свой MMU есть не только у дискретных карт, причем это далеко не новая технология. Интересно почему так. > Основная фича ускорителя в основном куча SIMD-образных крушилок. Очень сильное упрощение. Можно прировнять будет, только тогда, когда останется mesh-шейдеры с трассировкой лучей (при том, что аппаратный тайлинг никуда не делся). Но этого не будет, так как чистая считалка одна из многих областей применения. Для мобильных GPU на долгие годы останется хитрый конвейер (спойлер: этапов там больше, чем описаны в спеках OGL/Vulkan) с хитрым аппаратным растеризатором (ну и аппаратным тайлингом) + аппаратный (де)кодировщик. И чтобы это все быстро выключалось, а также быстро включалось (дабы экономить батарею). Поэтому набрать самый большой FLOPS не является приоритетной задачей. Нейронку тебе на мобильном GPU никто не будет запускать, для этого есть VPU/NPU блок (может сразу в камере, поэтому многие хуже работают без сладких блобов в LineageOS том же). Красивый графоний конечно нужен, но также нужно, чтобы телефон через 5 минут не вырубился. По этому пункту вы не правы.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	153. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (153), 05-Окт-23, 04:53
	Поправка: тайлинг и пастеризация это одно и тоже (лень авторизироваться).
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (-), 05-Окт-23, 16:31
	> Я не работал с амд на уровне допиливания прошивки (только на уровне > драйвера), но сейчас занимаюсь этим для PowerVR. А тут в топике про ARMовские дизайны, у них я вообще сервисных ядер так сразу не припоминаю как минимум у старых, просто конвееры для pixel/fragment shaders, еще и деление вычислителей по типам таскали до упора. > Именно в самой прошивки и создаются различные кучи инстансов устройства > (к счастью без виртуализации она всего одна) и MMU там нужен для наложения > всего этого. Ну вот как оно у PowerVR я не знаю, помню что на них народ плевался что это почти целиком firmware-based дизайн. Он возможно даже амд в этом переплюнул. И я не совсем понимаю как такой дизайн дружественно опенсорцу забацать, если вообще все на здоровенной фирмваре держится. Какие у этих господ планы на этот счет? Я так понимаю что с таким дизайном драйвер будет иметь чертову кучу лимитов что он (не)может без изменения фирмвары. А она так и будет проприетарная же, нет? > Предположил, что Mali +- одного класса устройства как PowerVR блоки, поэтому предположил, > что и в прошивки это все реализовано. У как минимум старых MALI я вообще никаких прошивок не припоминаю, у самых новых может что и пропустил, не смотрел самые новые. > Сейчас зашел в реализацию panfrost и там действительно mmu на уровне драйвера > работает (CPU), был не прав (ARM, получается, не осилили?) У них дизайн в целом сильно проще и педальнее как я понимаю. У старых даже с делением на типы шейдеров, что вообще-то голимо и архаично но уж как есть. > atombios взял, потому что: у них довольная солидная таблица команд, для управления > микрухи (ну и прошивки которая крутится на ней) и по коду > становится понятно, что там отдельный управляющий блок с отдельной rtos. Там несколько сервисных процессоров есть. Но как я понимаю в конечном итоге драйвре команды в очередь кидает и немало действа и сам код основной части GPU устраивает (в том числе и работу с его MMU?) а сервисные процы заведуют больше вспомогаловкой. Ну скажем SMU - заведует DVFS и вентилями, насколько я помню. Фирмварь этому вообще снаружи догружают при переходе в нативный режим, там же и сетап интересных таблиц, которые могут вообще перекрыть VBIOS - OEMы любят вписывать в таблицы какую-то жесть, потом нашлепав этого жутко жалеют о содеяном и вот амд придумало для этих неудачников вбивать оверрайды в драйвер. Но я смотрел относительно поверхностно, меня в драйвере сильно некоторые баги интересовали, в основном в районе того что они с контроллером памяти делают и SMU по части вольтажей-частот. > В PowerVR там проще: настройка pagetable'ов как раз для MMU (по факту > pool dma памяти передается по регистрам), наложение прошивки на heap устройства > и, собственно, отправка адреса на начало boot секции в регистр. Простите, а MMU - чьего для начала? ARM'а? GPU? Они в PowerVR делят 1 на 2, или чего? У амд то есть MMU со стороны GPU, и даже GPU-side paging. Есть адреса и страницы - в терминах GPU, x86 про это вообще ничего не знает, кроме как драйвер видяхи. В этом плане AMD GPU по сути отдельный комп на шине. А еще IOMMU есть, он доступы железа арбитрирует, и когда разговор про MMU неплохо уточнять какого из и как это все работает. Как видите там довольно по разному бывает и вот что что а у ARM врядли есть paging на стороне GPU c адресами и страницами GPU, они не настолько разогнались чтобы по сути отдельный комп сделать. > Написал, что был не прав. Но вообще, свой MMU есть не только > у дискретных карт, причем это далеко не новая технология. Интересно почему так. Кажется, по мере того как народ хочет унифицированые считалки под все и вся, оно все больше на отдельный компьютер смахивает. А вот этот процесс эволюции сильно размазан по вендорам. В этом смысле ARMовские дизайны "более винтажные" в каком-то смысле. В том плане что десктопные GPU например давно ушли от таких идей. >> Основная фича ускорителя в основном куча SIMD-образных крушилок. > Очень сильное упрощение. Можно прировнять будет, только тогда, когда останется mesh-шейдеры > с трассировкой лучей (при том, что аппаратный тайлинг никуда не делся). GPGPU compute только вон тем и пользуется например. На трассировку лучей там кстати похрен. > (спойлер: этапов там больше, чем описаны в спеках OGL/Vulkan) с хитрым > аппаратным растеризатором (ну и аппаратным тайлингом) + аппаратный (де)кодировщик. Ээээ там же и декодер видео? А то обычно это отделный IP блок, вообще не связанный с вон тем. Скажем у allwinner или rockchip это 100% отдельные блоки, никак вообще с сабжем не связанные. А пересекаются они хоть как-то разве что в Display Controller по вопросам кто в какой surface рисует и что в сумме на экран будет. В этом плане у них всех есть нечто общее: у почти всех есть некие хардварные оверлеи/слои, в основном для вывода видео за хардварным декодером как раз. При том Display Controller так то тоже отделные железки, это только в десктопных в 1 железку универсально встроено, а у ARM это независимая железка. Дизайн KMS/DRM с неких пор учел такое деление выделив render nodes vs compute nodes. И оно могет жить с вот этим, когда может быть долбилка на экран без считалок, считалка без вывода на экран, или какое-то комбо первого и второго. Так и вон то представимо, и dGPU, и даже акселераторы безголовые. Да что там вон Habana вообще NPU но тоже хочет это все юзать, потому что для счета инфраструктура и им катит в принципе. > И чтобы это все быстро выключалось, а также быстро включалось (дабы экономить батарею). У амд довольно забавные технологии на этот счет, но я смотрел только относительно старые, без наворотов типа BACO (bus active chip off) и проч. А так там сервисный процик очень шустро менеджит DVFS по нагрузке, со временем его даже научили в овердрафт уходить, когда можно кратковременно шпарить более чем долговременно выдерживаемый режим, но если продолжается, то снизить клок до долговременно перевариваемого, и тому подобные вещи. Но они больше на перфоманс ориентированы. > Поэтому набрать самый большой FLOPS не является приоритетной задачей. Нейронку тебе > на мобильном GPU никто не будет запускать, для этого есть VPU/NPU блок Ну на мелочи это не развито. И там так то забавные TOPS иногда бывают у этих штук :) > (может сразу в камере, поэтому многие хуже работают без сладких > блобов в LineageOS том же). Камера никак не поможет для других применений VPU/NPU, так что это туповатый дизайн имхо. > Красивый графоний конечно нужен, но также нужно, чтобы телефон через 5 минут > не вырубился. По этому пункту вы не правы. Ээээ.... нельзя ли поподробнее на этот счет?
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	111. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Sw00p aka Jerom (?), 04-Окт-23, 00:33
	>Очень мощная техническая бурда. а че вы ожидали от ЧатГопоты? софт-скилы ептить :)
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

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

	8. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–4 +/–
	Сообщение от birdie (ok), 03-Окт-23, 15:19
	> И дайте угадаю, старые устройства обновить практически нереально. Enjoy. Enjoy the monolithic Linux kernel with unstable API/ABI which requires constant maintenance for all third party drivers or special type of sex with kernel maintainers who require near-perfect code to get it merged? Yes, right.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (19), 03-Окт-23, 16:09
	Причём здесь unstable ABI в ядре, если ведроидные драйвера работают в юзерспейсе?
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (43), 03-Окт-23, 16:57
	а вот здесь сказано, что нет https://source.android.com/docs/core/architecture/kernel и vendor modules там являются загружаемыми модулями ядра так что с тебя пруф, что в данном случае эти самые vendor modules для данной аппаратуры являются лишь тонким слоем, выносящим работу в userspace ну и сама бага как бы намекает нам > CVE-2023-4211 - выполнение некорректной операции с памятью GPU может привести к получению доступа к уже освобождённой системной памяти, которая может быть задействована в процессе выполнения других задач в ядре в ядре
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от birdie (ok), 04-Окт-23, 03:28
	> Причём здесь unstable ABI в ядре, если ведроидные драйвера работают в юзерспейсе? Что вы несёте я не могу понять. Там такое же ядро, только хуже - полный монолит без модулей.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

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

	131. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от RM (ok), 04-Окт-23, 12:49
	>seL4 которое, кстати, еще и верифицировнно предлагаю погуглить среднюю цену строчки кода и цену строчки кода в se4L
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–1 +/–
	Сообщение от Kuromi (ok), 03-Окт-23, 15:35
	Ну так "Настало время покупать новые устройсва!". Все по плану же. Вспомните сколько Гугл бодался с производителями чтобы те хотя бы немного обновляли свои железки? И каждый раз находились все новые "проблемы" и причины почему ну нет никакой возможности выпустить обновление. В мире кризис, падение продаж, зеленоватые антиконсумеристы повылезали и призывают меньше потреблять, мол "Земля не резиновая", а ты еще и обновлять старые телефоны предложил? В США 50-ых за такое сразу в комми записывали и брали на карандаш!
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

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

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

	30. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от фнон (?), 03-Окт-23, 16:18
	Сомневаюсь Гугл тут соперничает с эплом, и приходится делать "не хуже чем у конкурента", вот недавно поддержку хромо-оси продлили до 10 лет. Так что я бы ожидал минимум 6 лет - как у айфонов, а может даже больше, чтобы можно было померяться длинной поддержки в рекламных материалах.
	Ответить | Правка | Наверх | Cообщить модератору

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

	101. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (99), 03-Окт-23, 22:46
	Вот только никто никогда не планировал никаких телефонов на Фуксии(а Фикция это уже твой пьяный бред)
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	77. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от uis (??), 03-Окт-23, 20:17
	Рукожопы ARM, а виноват как всегда линукс
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	81. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (81), 03-Окт-23, 20:37
	да 👆! концепция линукса, изначально ошибочная и ущербная. no discussion!
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от YetAnotherOnanym (ok), 03-Окт-23, 20:07
	Вот и хорошо, можно получить рута (или даже получать рута каждый раз, когда это нужно, не превращая телефон в явно рутованный).
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	124. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (99), 04-Окт-23, 10:02
	Проблема наблюдается в Pixel 7 и его ровесниках, а ты про "старые телефоны не обновить" Проблема только в моделях последнего года, которые получают штатные обновления даже у самых подвальных Куботов
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

48. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–2 +/–
Сообщение от Аноним (-), 03-Окт-23, 17:25
>Три критические проблемы (CVE-2023-24855, CVE-2023-28540 и CVE-2023-33028) выявлены в проприетарных компонентах Ах вот почему хейтеры Сишки молчат в тряпочку! Уязвимости оказались в проприетарных компонентах.
Ответить | Правка | Наверх | Cообщить модератору

	50. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Анонин (?), 03-Окт-23, 17:34
	> в проприетарных компонентах. которые тоже были написаны на сишечке?
	Ответить | Правка | Наверх | Cообщить модератору

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

	55. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–2 +/–
	Сообщение от Аноним (1), 03-Окт-23, 18:07
	хаха, гугл который часть андроида пишет на раст (как раз по причине подобных memory ошибок) смеется тебе в лицо https://security.googleblog.com/2022/12/memory-safe-language...
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (1), 03-Окт-23, 17:43
	а какое отношение открытость/закрытость, вид лицензии и т.д. влияют на язык приложения? дыряшка, дыряшка никогда не меняется - как выходили за пределы массива и делали double free 30 лет назад, так и продолжают это скорее показывают что высокая зарплата, что тысячи глаз - результат почти одинаковый (хотя судя по 15 летним уязвимостям в ядре - скорее тысячи глаз увидят, и пойдут зарабатывать на черном рынке)
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	109. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–2 +/–
	Сообщение от Аноним (109), 04-Окт-23, 00:24
	> как выходили за пределы массива и делали double free 30 лет назад Если язык такое не позволяет, то такой язык нахер не годится для написания ОС.
	Ответить | Правка | Наверх | Cообщить модератору

75. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–1 +/–
Сообщение от Аноним (-), 03-Окт-23, 20:07
ARM это телефонный мусор. Пора бы некоторым товарищам понять это, что единственная нормальная архитектура это x86 и от того и самая распространённая.
Ответить | Правка | Наверх | Cообщить модератору

	169. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–1 +/–
	Сообщение от Аноним (169), 05-Окт-23, 15:18
	ARM это еще и одноплатники, яблобуки, ябломини - в общем не всегда совсем тощая дурь. Их мощностей как иу  атома вполне хватит для офисной работы. А единственная нормальная архитектура это e2k - он же Эльбрус. Никакой подставы в процессоре. Невозможность совершить атаки вирусами существующими и так далее.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Аноним (180), 05-Окт-23, 16:39
	> ARM это еще и одноплатники, яблобуки, ябломини - в общем не всегда > совсем тощая дурь. Их мощностей как иу  атома вполне хватит > для офисной работы. > А единственная нормальная архитектура это e2k - он же Эльбрус. Никакой подставы > в процессоре. Невозможность совершить атаки вирусами существующими и так далее. А еще... 1) Нету открытого компилера по сути. 2) Все изменения кишок немедленно отливаются на уровне ABI. 3) Майнлайновый кернел это тоже не поддерживает. 4) За ...цать лет этого действа результат очень близок к нолю. А так все хорошо прекрасная маркиза. Отличная архитектура.
	Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
Сообщение от uis (??), 03-Окт-23, 20:21
Надо было ставить что? Lima!
Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от uis (??), 03-Окт-23, 20:24
	Или Panfrost
	Ответить | Правка | Наверх | Cообщить модератору

82. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
Сообщение от Аноним (82), 03-Окт-23, 20:41
Раз уж речь зашла о Си, то недавно обнаружил весьма люботный факт, - может кто-нибудь знает почему создатели функции fgets() решили что бесконечный цикл это круто, если второй аргумент будет равен единице? Нет, я конечно всё понимаю, что такое практически никогда не случается, но блин могли бы хотя написать об этом в документации:( ПС: мда... и только в проекте OpenBSD удосужились об этом написать: Whether fgets() can possibly fail with a size argument of 1 is implementation-dependent. On OpenBSD, fgets() will never return NULL when size is 1.
Ответить | Правка | Наверх | Cообщить модератору

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

	110. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (109), 04-Окт-23, 00:27
	Напиши свою fgets()
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	119. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Аноним (119), 04-Окт-23, 08:53
	Стандартный ввод/вывод в Си — это хтонический ужас. Собственно, он во всех древних языках такой был, н только в сишечке до наших дней дожил.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	177. Скрыто модератором	+/–
	Сообщение от Аноним (-), 05-Окт-23, 16:30
	Поробуй потоньше, а то что-то толсто.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от InuYasha (??), 05-Окт-23, 18:52
	Да не только И/О, а все строковые утилиты. Все что мне были нужны я переписал под свои нужды сам. И так сделал каждый программист :D
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	130. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (130), 04-Окт-23, 11:52
	> Раз уж речь зашла о Си, то недавно обнаружил весьма люботный факт, > - может кто-нибудь знает почему создатели функции fgets() решили что бесконечный > цикл это круто, если второй аргумент будет равен единице? Какие создатели и чего именно? The fgets function reads at most one less than the number of characters specified by n from the stream pointed to by stream into the array pointed to by s. No additional characters are read after a new-line character (which is retained) or after end-of-file. A null character is written immediately after the last character read into the array. char * __fgets_unlocked (char *buf, int n, FILE *fp) {   size_t count;   char *result;   int old_error;   CHECK_FILE (fp, NULL);   if (n <= 0)     return NULL;   if (__glibc_unlikely (n == 1))     {       /* Another irregular case: since we have to store a NUL byte and      there is only room for exactly one byte, we don't have to      read anything.  */       buf[0] = '\0';       return buf;     }
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	133. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (82), 04-Окт-23, 15:18
	Т.е вы считаете, что если пользователь получает бесконечный цикл, при n равным единице, то это нормально? Или вы считаете нормальным не указать об этом в документации (в тексте, который вы привели, - нет ни  слова об этом!)?? Т.е по вашему, я должен лезть в исходники чтобы понять, почему происходит такой бред???
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (130), 04-Окт-23, 15:34
	Я не вижу ни цикла в вышеприведённом коде, ни требований в стандарте зацикливать при n == 1. Если хочешь, что бы я перестал считать тебя троллем, потрудись привести минимальный пример, а так же укажи версию компилятора и библиотеки.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (82), 04-Окт-23, 16:55
	>>> Я не вижу ни цикла в вышеприведённом коде <<< Смысл в том что, скорее всего вы будете использовать fgets таким образом: while (fgets(buff, bsize, stdin) != NULL)     puts("WTF?"); А теперь, внимание, что случится если buff это динамический массив, а его размер bsize будет равен единице?
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (82), 04-Окт-23, 17:02
	ПС: для наглядной иллюстрации для простоты просто возьмите статический массив размером 1. #include <stdio.h> #define BSIZE 1 int main(void) {     char buff[BSIZE];     while (fgets(buff, BSIZE, stdin) != NULL)         puts("WTF?");     return 0; }
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Совершенно другой аноним (?), 05-Окт-23, 12:31
	Ну, как-бы, Вы сами функцию зациклили. Аналогичное поведение будет, если Вы укажите вместо stdin, например, NULL.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Аноним (130), 05-Окт-23, 13:19
	Показательный пример, кстати. Если fgets заменить на true - тогда виновата во всём окажется истина. :)
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (82), 05-Окт-23, 15:15
	>>> Ну, как-бы, Вы сами функцию зациклили <<< Моя претензия в том, что о такой дичи нужно писать в документации, как это сделали в проекте OpenBSD!!! ПС: В общем, не удивительно, что в мире Си такой лютый треш творится, если великие гуру не могут просто взять и сделать нормальынй API.
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

	187. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Совершенно другой аноним (?), 06-Окт-23, 08:41
	>>>> Ну, как-бы, Вы сами функцию зациклили <<< > Моя претензия в том, что о такой дичи нужно писать в документации, > как это сделали в проекте OpenBSD!!! > ПС: В общем, не удивительно, что в мире Си такой лютый треш > творится, если великие гуру не могут просто взять и сделать нормальынй > API. Честно говоря, за около 20-ти летний опыт использования языка С, как-то ниразу не приходилось читать в однобайтовый буфер данные при помощи функции fgets().
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (82), 06-Окт-23, 10:13
	Я сам был мягко говоря удивлён! Проблема в том, что там использовался динамический массив, а не статический, размер которого задаётся пользователем! Уж не спрашивайте кто и зачем такое придумал, для меня это тоже загадка:)
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Совершенно другой аноним (?), 05-Окт-23, 13:23
	В том плане - фунция fgets() ожидает буфер, имеющий возможность хранить как минимум один введённый символ и признак окончания строки '\0'. В стандарте про значение n написано явно, что оно должно быть на 1 меньше, чем хотят ввести данных. Может "диды" не догадывались, что потомки будут хотеть, по факту, ввести 0 символов. Как Вам привели выше, в glibc от этой ситуации явно защитились, даже комментарий написали, и в таком случае говорят, что ввод прошел нормально, и в буфер записывают символ с кодом '\0'. Формально они поступают правильно - ошибки именно ввода-вывода не было, попросили ввести 0 символов - получите. NULL они вернуть не могут, потом-как его возвращают ТОЛЬКО по ошибке ввода, которого небыло. Как в том анекдоте: - Товарищ полковник, Ваше приказание выполнено! - Так я ничего не приказывал!! - Так мы ничего и не делали!!!
	Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

	189. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (82), 06-Окт-23, 10:29
	что потомки будут хотеть, по факту, ввести 0 символов. Дьявол кроется в деталях! Обработка ошибок это вообще целая наука; лично я сторонник того, что не надо делать никаких предположений; именно из-за такого рода мелочей и получаем кучу уязвимостей и крики о том что Си это дырень и нытьё о том что его пора закопать; ПС: проблема не в языке Си как таковом (хотя они там есть), а в том что большинство функции, даже в стандартной библиотеке, НЕнадёжны и являются откровенным куском говна (чего только стоят strncpy и strncat - кто вообще в здравом уме мог такое придумать?), - может в бородатые 80-е этого и было достаточно, - но времена изменились!
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Аноним (130), 05-Окт-23, 13:07
	>>>> Я не вижу ни цикла в вышеприведённом коде <<< > Смысл в том что, скорее всего вы будете использовать fgets таким образом: > while (fgets(buff, bsize, stdin) != NULL) >     puts("WTF?"); Не буду. > А теперь, внимание, что случится если buff это динамический массив, а его > размер bsize будет равен единице? Случилось: 1. выдумывание глупости; 2. приписывание её оппоненту; 3. ненавязчивое предложение с этой глупостью поспорить.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	170. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (82), 05-Окт-23, 15:20
	>> Не буду. <<< Да я и сам выкинул это гумно на помойку и написал свою версию c нормальным API, где нет никакого неопределённого поведения.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (82), 05-Окт-23, 15:24
	>>> выдумывание глупости; <<< это не моя глупость:), а реальность с которой мне пришлось недавно столкнуться в продакте:(
	Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
Сообщение от ИмяХ (?), 03-Окт-23, 21:05
Спасибо, что раскрыли сведения. Теперь эти уязвимости будут юзать все кому не лень.
Ответить | Правка | Наверх | Cообщить модератору

125. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
Сообщение от Пряник (?), 04-Окт-23, 10:15
> Например, уязвимость может применяться в распространяемых через сомнительные источники вредоносных приложениях для получения полного доступа к системе и установки компонентов, шпионящих за пользователем. Прилаги из гугл плей тоже могут И БУДУТ! Думаете им достаточно будет разрешения смотреть в наши контакты, смс, вай-фай точки, геолокацию (напомню, что геолокация работает даже без спутников по вайфай и сотовым сигналам - триангуляция)?
Ответить | Правка | Наверх | Cообщить модератору

	154. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Бывалый смузихлёб (?), 05-Окт-23, 09:16
	откуда блок заранее знает, где конкретно находится какая вышка или вайфай-раздача ?
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Пряник (?), 05-Окт-23, 10:07
	Гугл собирает базу данных со инфой о всех вышках и точках вай фай (незаметно для нас). Когда мы включаем GPS, то он ещё и собирает геокоординаты вышек и точек вай фай. Теперь зная GPS координаты всех вышек и точек вай фай смартфон может по уровню сигнала до двух любых из них определить свои координаты с точностью до метра. Вся эта канитель назвается Network Location Provider. Есть даже опен сорс замены (UnifiedNlp), позволяющие у себя на смарте вести базу данных и никому её не сливать.
	Ответить | Правка | Наверх | Cообщить модератору

134. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
Сообщение от nymous (?), 04-Окт-23, 15:31
Регулярно пишут про уязвимости в андроиде. Но почему-то не слышно про вирусы, которые распространялись бы в этой экосистеме. Вот виндо-вирусы в своё время были распространены...
Ответить | Правка | Наверх | Cообщить модератору

	146. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+1 +/–
	Сообщение от Аноним (-), 04-Окт-23, 18:56
	Дай угадаю, ты живёшь в стране эльфов и в ней в салонах связи не продают телефоны с адварью?
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от nymous (?), 05-Окт-23, 11:05
	Адварь в прошивке, заботливо приготовленная производителем - это одно. А вирус, который бы сам распространялся от смарта к смарту - это другое.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–1 +/–
	Сообщение от Аноним (-), 06-Окт-23, 07:55
	> Адварь в прошивке, заботливо приготовленная производителем - это одно. Там еще спайварь есть, сливающая все вплоть до паролей на точки доступа, и малварь в виде откровенно нежелательного поведения типа неудаляемых программ. > А вирус, который бы сам распространялся от смарта к смарту - это другое. Не вижу отличий между малварью и малварью.
	Ответить | Правка | Наверх | Cообщить модератору

147. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	–1 +/–
Сообщение от Бульдох (?), 04-Окт-23, 20:31
А вам не кажется, что все эти "уязвимости" нацелены лишь на то, чтобы плебс приобретал новые процессоры роняя ...?
Ответить | Правка | Наверх | Cообщить модератору

	192. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."	+/–
	Сообщение от Аноним (99), 06-Окт-23, 21:22
	Вера в теорию заговора - признак психической болезни Сходи ко врачу
	Ответить | Правка | Наверх | Cообщить модератору

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

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