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

Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально позволяющая выполнить код, opennews (??), 16-Дек-21, (0) [смотреть все] Да блин Опять все из за Сей, с их буфферами ограниченного размера, создаваемыми, Аноним (1), 09:27 , 16-Дек-21, (1) –29 // На сях можно выделить память на куче и работать с ней При чём тут си Тут ошибк, Корец (?), 09:36 , 16-Дек-21, (4) +15 // а когда кучу надо освободить 8212 это всегда безопасная процедура , Аноним (10), 09:56 , 16-Дек-21, (10) –11   // На стеке -- да Но никак не в куче А вообще, Си доказал давно свою профнепригод, Брат Анон (ok), 10:05 , 16-Дек-21, (15) –18   Пока что, лишь Анон доказал давно свою профнепригодность , InuYasha (??), 10:14 , 16-Дек-21, (19) +16   При выполнении пары правил что само по себе не очень идея -- можно Си по опред, Брат Анон (ok), 11:08 , 16-Дек-21, (43) –2   зарубите на носу и держитесь подальше, ибо язык это не для незнаек и недоучек, я, Sw00p aka Jerom (?), 11:35 , 16-Дек-21, (56)   Значит ядро с такими уязвимостями писали знайки и доучки, да , Rev (?), 13:33 , 16-Дек-21, (67) +5   а ядро причем никто не запрещает незнайкам и недоучкам писать ядро, а раз в ядр, Sw00p aka Jerom (?), 14:11 , 16-Дек-21, (72) –3   И рецензировали написанное - тоже незнайки-недоучки, а не сферическо-пряморукие , _ (??), 14:41 , 16-Дек-21, (77) +3   выходит так, спросите у того кто проводил рецензию Не знание тонкостей работы с, Sw00p aka Jerom (?), 17:07 , 16-Дек-21, (89) –1   Если двумя разными инструментами можно сделать одну и ту же работу, только для т, Прохожий (??), 07:29 , 17-Дек-21, (117)   Потребительская логика, легче купить продукт , Sw00p aka Jerom (?), 11:15 , 17-Дек-21, (124)   легче купить нового раба с нужными знаниями, амоним (?), 18:11 , 17-Дек-21, (135)   А значит ядро нужно писать не на Си А то незнайки и недоучки делают много ляпов, Аноним (95), 20:13 , 16-Дек-21, (95)   отличная логика, незнайка и недоучка по определению не должен писать не на Си ни, Sw00p aka Jerom (?), 21:52 , 16-Дек-21, (98) +1   а кто доучка практика показвывает, что на си пишут исключительно недоучки, полу, искра (?), 04:05 , 17-Дек-21, (114) +1   ну а шо поделаешь, если в школе вам будут за место математики преподавать всякую, Sw00p aka Jerom (?), 11:22 , 17-Дек-21, (125)   Брат Анон, тебе в ЯОС , Аноним (65), 13:23 , 16-Дек-21, (65) +1   Ну а что - тоже хорошие 3 буквы, и означают наверное то-же самое , _ (??), 23:44 , 16-Дек-21, (100)   Аноним, ты так это написал, как-будто в этом есть что-то плохое И тебя сейчас н, Брат Анон (ok), 18:28 , 19-Дек-21, (146)   Си еще ладно Машинные коды вообще никуда не годятся , Анонм (?), 10:19 , 16-Дек-21, (23)   Машинные коды не язык И не переносимо Хреновая идея , Брат Анон (ok), 11:09 , 16-Дек-21, (44)   А по мне так отличная Одна железка -- одна программа, гы Как у макосексуалисто, псевдонимус (?), 11:31 , 16-Дек-21, (51) +2   Полностью согла надменно-осуждающие лица дизайнеров из соседней комнаты сен, InuYasha (??), 17:30 , 16-Дек-21, (90) +2   Но ведь и правда, что нужно ассемблеры, Фортран, тикль и Шелл Ну ладно, ц и, псевдонимус (?), 19:00 , 16-Дек-21, (93)   и жаба - для индусови раст - для и пеЙтон - для школотыи ребе - для заморо, _ (??), 23:49 , 16-Дек-21, (101)   Мля, япро форт забыл В принципе достаточно его одного Лучший язык всех времён , псевдонимус (?), 19:02 , 16-Дек-21, (94)   Дык все глупости в этом мире сделаны с серьёзным выражение лица С Барон Мюнхг, _ (??), 23:51 , 16-Дек-21, (102)   не мешайте глупцам совершать глупости ц Барон Жером , Sw00p aka Jerom (?), 12:02 , 17-Дек-21, (127)   Бегите, глупцы ц Гендо т е Гендальф , InuYasha (??), 12:32 , 17-Дек-21, (129)   С доказывает только профнепригодность программистов, которые пишут программы не , Sw00p aka Jerom (?), 11:32 , 16-Дек-21, (53) +4   Чтоб об этом думать - надо об этом знатьПоследних много лет идет снижение порога, Аноним (110), 01:37 , 17-Дек-21, (110)   ну и к чему приведет снижение этого порога Можно ли опустить допустим знания пр, Sw00p aka Jerom (?), 11:29 , 17-Дек-21, (126)   К усилению позиции корпорации-инициатора Корпорация может себе позволить нанять , Аноним (110), 03:26 , 18-Дек-21, (137)   В чужой стране - просто необходимо Убить системный подход в образовании самый си, Аноним (110), 03:34 , 18-Дек-21, (138)   план даллеса курит в сторонке, серьезно хотелось бы написать про самообразовани, Sw00p aka Jerom (?), 11:16 , 18-Дек-21, (140)   Не догоняю в чем разница Если тебе в стек напишут данные в уже освобождённый бу, x3who (?), 12:38 , 16-Дек-21, (61) +1   Такая запись не испортит актуальные данные, если не выйдет за границы стека в я, n00by (ok), 13:51 , 16-Дек-21, (69) +3   Во-первых испортит, если все данные будут храниться на стеке Во-вторых появляет, x3who (?), 12:57 , 17-Дек-21, (130)   Тут надо понимать, что такое вершина стека, которую адресует указатель стека Об, n00by (ok), 15:00 , 17-Дек-21, (131)   совершенно необязательно, что именно сюда только сюда И даже что пишем необязат, x3who (?), 10:22 , 18-Дек-21, (139)   Желательно помнить контекст 10 а когда кучу надо освободить 8212 это все, n00by (ok), 11:16 , 18-Дек-21, (141)   Не всегда Вот пример какой-то код фызвал функцию, которая разместила буфер на , x3who (?), 12:30 , 18-Дек-21, (142)   Это следует из определения Цитирую System V Application Binary Interface AMD64 , n00by (ok), 13:38 , 18-Дек-21, (143)   Не должен бы Не знаю, но подозреваю, что кернельские треды уже имеют преаллоцир, x3who (?), 15:20 , 18-Дек-21, (144)   Если освобождаемый блок окажется последним занятым в странице памяти, менеджер к, n00by (ok), 17:21 , 18-Дек-21, (145)   Скрыто модератором, Аноним (-), 08:28 , 23-Дек-21, (147)   Да, если с освобождаемой памятью закончена работа и к ней больше не обращаться , Корец (?), 10:06 , 16-Дек-21, (16)   Да Как можно не знать таких основ азов, элементарщины Нельзя обращаться к осво, Аноним (41), 11:07 , 16-Дек-21, (41)   Если нельзя, но очень хочется реализовать сборку мусора по алгоритму mark-compac, n00by (ok), 13:55 , 16-Дек-21, (70)   Проблема в том, что при обращении за пределы своей памяти по умолчанию происхо, Анонн (?), 09:58 , 16-Дек-21, (12) –1 // Какая своя память , чужая память Это ядро и ring0, так-то , Онаним (?), 10:50 , 16-Дек-21, (36) +1 Можно это аргументировать так, что куча медленная, но можно же сделать что то ти, Аноним (1), 10:00 , 16-Дек-21, (13) –3 // Первый раз слышу Расскажи подробнее , Корец (?), 10:08 , 16-Дек-21, (18) +1 Как работает стек SUB RSP, 10HКак работает куча Найти свободный блокВыделить сво, Аноним (1), 10:33 , 16-Дек-21, (32) В х якс интелбои недоделанные реализация кучи для усера это malloc в libc, sbr, Аноним (-), 10:43 , 16-Дек-21, (33) –5 Ну да А malloc за счет духа святого работает Вот и выросло поколение, которое , Аноним (1), 10:56 , 16-Дек-21, (39) +6 в сообщении выше так и сказано динамической памятью занимается операционная сис, Аноним (-), 11:26 , 16-Дек-21, (49) –1 В рылотайме оно то сих пор не так, программирование его на древних процессорах в, szt1980 (ok), 23:52 , 16-Дек-21, (103) Собственно никто не заставляет использовать динамическое выделение памяти в свои, Аноним (-), 08:30 , 23-Дек-21, (148) И да По мне так AT T не православный асм, ибо куча знаков препинания ненужных , Аноним (1), 10:59 , 16-Дек-21, (40) –3 Злодеи они, запретили man alloca Впрочем, правильно сделали , n00by (ok), 14:36 , 16-Дек-21, (75) если не понимаешь о чем речь - проходи мимо, не позорься, Аноним (-), 14:53 , 16-Дек-21, (78) А о чём речь sbrk в ядре Азазазаза https www kernel org doc htmldocs kernel, n00by (ok), 14:57 , 16-Дек-21, (79) сейчас до тебя дойдет что это работа памятью в кернелспейсе продолжай перебо, Аноним (-), 15:46 , 16-Дек-21, (85) Работа с памятью в, цитирую новость подсистеме ядра Linux, происходит в кернелс, n00by (ok), 08:45 , 17-Дек-21, (120) man alloca, Аноним , Урри (ok), 11:35 , 16-Дек-21, (55) Может не будем языком молоть и просто проведем тест Скажем миллион раз сделаем m, Аноним (123), 09:54 , 17-Дек-21, (123) Аноним настолько туп, что не может отличить alloca от malloc Аноним НАСТОЛЬК, Урри (ok), 15:03 , 17-Дек-21, (132) 1 Ты забыл про путешествия в ядро за физическими страницами памяти, что для сте, x3who (?), 12:51 , 16-Дек-21, (63) gt оверквотинг удален Как и об этом x86_64 page size PAGE_SIZE is 4K Like al, n00by (ok), 14:30 , 16-Дек-21, (74) Можно, и даже уже сделано - в ядре есть и разные slab slub аллокаторы, и kmalloc, Совершенно другой аноним (?), 13:18 , 16-Дек-21, (64) да кстати, пацаны, почему каждая либа изобретает свой собственный менеджер памят, Аноним (5), 09:38 , 16-Дек-21, (5) // Можно Разрешаю , Иноагент (?), 10:15 , 16-Дек-21, (20) +2 потому что правильно и унифицированно не существует хоть и сказочки корпораст, lombock (?), 10:22 , 16-Дек-21, (25) +4 шоп на выхаде ты такой стоя спиной к эффектному взрыву говоришь - free xmlBuf ,, Аноним (-), 11:29 , 16-Дек-21, (50) –1 Так уже один ржавый язык придумал, так теперь огромная пачка олдфагов ходит и пе, Аноним (58), 11:59 , 16-Дек-21, (58) –1 // Очередной растишечка расписался в профнепригодности , Урри (ok), 13:23 , 16-Дек-21, (66) +2 ахаха, это пять , РастоманПитонофил (?), 15:37 , 16-Дек-21, (82) Это он сгоряча, он просто маны на unsafe на раст не читал , Аноним (-), 08:32 , 23-Дек-21, (149) В ядре Ну ладно, указанный случай ещё терпимо Но вот пожелаю вам в обработчиках , Онаним (?), 10:54 , 16-Дек-21, (38) +4 Ты когда молотком по пальцу попадаешь, это молоток виноват или это ты криворукий, BorichL (ok), 14:37 , 16-Дек-21, (76) –1 // Есть автоматизированные молотки Там тяжело, если вообще возможно, по пальцу поп, Прохожий (??), 07:44 , 17-Дек-21, (118) // Ну может по пальцу не попасть, а уж гвоздь в лоб забить то точно можно У нас пр, BorichL (ok), 16:58 , 17-Дек-21, (133) А придурок тот, кто этого не понимает , Прохожий (??), 07:45 , 17-Дек-21, (119) // Не, придурок тот, кто думает, что автоматика за него всё сделает, а он только кн, BorichL (ok), 17:00 , 17-Дек-21, (134) Так его как раз и уволят - кнопку так то и робот жать может, да и кнопку можно у, Аноним (-), 08:33 , 23-Дек-21, (150) Именно так - Сейчас нейросети научат растоманить и все безопасные программис, BorichL (ok), 14:02 , 23-Дек-21, (155) Потом от вашей динамической памяти страдают целые сервера программировать нормал, richman1000000 (ok), 15:44 , 16-Дек-21, (84) Пока ядро не переведут на более адекватные языки - оно так и будет рассадником д, Аноним (3), 09:36 , 16-Дек-21, (3) –12 // Я даже знаю, какой адекватный язык вы имеете ввиду, Аноним12345 (?), 09:48 , 16-Дек-21, (7) +6 // Догадаться нетрудно, Fracta1L (ok), 10:31 , 16-Дек-21, (30) +5 // Ты на нем попробуй напищи чего-нить там что не действие то боль сплошная А в, Аноним (58), 12:01 , 16-Дек-21, (59) Ахахаха, это пять , Fracta1L (ok), 12:44 , 16-Дек-21, (62) –1 Покажи свои проекты на расте, чудик Ты вообще видел шоу с поддержкой раста в яд, Аноним (-), 08:36 , 23-Дек-21, (151) Вот карапузы и ваяют эти уязвимости как раз Не смог разобраться в Расте - не , Rev (?), 13:37 , 16-Дек-21, (68) +1 Не смог осилить элементарный C не лезь вообще никуда Улицы убирай, срачь кругом, РастоманПитонофил (?), 15:38 , 16-Дек-21, (83) +2 https www misra org uk misra-c https wiki sei cmu edu confluence display c S, _ (??), 16:13 , 16-Дек-21, (88) Предлагаешь всем без исключения программистам на сишке пойти мести улицы какая , Fracta1L (ok), 09:09 , 17-Дек-21, (121) А ядро тебе кто будет тогда патчить, чтобы ты тут мог умные коменты строчить , Аноним (-), 08:36 , 23-Дек-21, (152) точно этот язык 8212 D, искра (?), 04:08 , 17-Дек-21, (115) Кстати, интересный язык Всё хочу на нём свой пакетный менеджер переписать , Fracta1L (ok), 09:09 , 17-Дек-21, (122) вот о чем я говорил, калькулятор вменяемый сначала напишите, а дальше хоть ядро , Sw00p aka Jerom (?), 12:05 , 17-Дек-21, (128) Ты на нем хоть что-нибудь написать смог Синтаксис у него больно уж кислотнен, Аноним (-), 08:37 , 23-Дек-21, (153) В каком смысле Там же вроде питоноподобный синтаксис , Fracta1L (ok), 08:58 , 23-Дек-21, (154) Да все знают Нет ядра - нет дыр , Урри (ok), 11:37 , 16-Дек-21, (57) На яваскрипт, что ли , Анонм (?), 09:53 , 16-Дек-21, (9) +4 // пф хуже этой солянки даже не знаю что сыскать, разве что c golang rust, Аноним (10), 10:05 , 16-Дек-21, (14) –4 // Что в этом списке делает golang Тонны годного софта на нём И не падает , Брат Анон (ok), 10:06 , 16-Дек-21, (17) +4 тонко, особенно про годный D, Аноним (-), 10:45 , 16-Дек-21, (34) –3 В каждой шутке -- лишь доля шутки Всё остальное правда , Брат Анон (ok), 11:10 , 16-Дек-21, (45) +2 почти не падает растяжимое понятие, раз в час это тоже почти , Аноним (-), 11:32 , 16-Дек-21, (52) –1 Главное заставить других верить в эту правду, да , Аноним (87), 16:03 , 16-Дек-21, (87) –1 - Тут 12309 опять вернулся - Да врёте вы всё, это сборка мусора в ядре , AlexVRud (ok), 11:21 , 16-Дек-21, (47) +1 проснись, соня, уже давно почему не пользуешься а дистриб почему не сделал htt, lombock (?), 10:25 , 16-Дек-21, (26) +2 ЕСЛИ дыра_в_ядре РАВНО ЕСТЬ НЦ ПЕЧАТЬ кавычка Обноружена дыра в ядре , Анонм (?), 10:27 , 16-Дек-21, (27) +2 // Будяк Д В, перелогиньтесь, vitalif (ok), 02:12 , 18-Дек-21, (136) какие адекватные , lombock (?), 10:29 , 16-Дек-21, (29) // C , Java, Python или любой другой язык с управлением памятью, Аноним (87), 16:01 , 16-Дек-21, (86) // Иди ты на фиг, прерываеие реального времени, у меня тут GC работает, не до тебя, Аноним (91), 18:27 , 16-Дек-21, (91) И слышавшие звон опоздавшие родиться - пусть идут туда же , _ (??), 18:55 , 16-Дек-21, (92) Эвон чего откопали Как у него с оверхэдом было Как у обычной явы, я полагаю С, Хероптерикс (?), 21:08 , 16-Дек-21, (96) –1 Занятный спрыг с темы Опеннетно-классический Ну, запретить опеннетчикам писать , _ (??), 21:42 , 16-Дек-21, (97) Т е по теме аргументов нет, кроме сам дурак Ок, ясно-понятно , Аноним (91), 23:55 , 16-Дек-21, (104) Т е ты сам шутсро спрыгнул с темы Иди ты на фиг, прерываеие реального времени,, _ (??), 00:42 , 17-Дек-21, (106) Прерывания С 10x оверхедом С динамическим выделением памяти С кеш-промахами в, Аноним (91), 01:42 , 17-Дек-21, (111) Memory ManagementGarbage-collected memory heaps have always been considered a, _ (??), 01:54 , 17-Дек-21, (112) Да, мне тоже пришлось это прочитать, когда вы упомянули RTSJ Да, они частично , Аноним (91), 02:10 , 17-Дек-21, (113) т е до 64 КБ включительно, т е просто 64 КБ, а не почему то 65 КБ , изнасилованжурналистом50летназад (?), 09:39 , 16-Дек-21, (6) // Акция 1 Кб в подарок , Аноним (8), 09:49 , 16-Дек-21, (8) +6 // Ага Это как во времена AT Купи 640Кб, 65520 в подарок , Аноним (1), 09:57 , 16-Дек-21, (11) Нет До 65 КБ - это 64 КБ плюс 1023 байт 999 если СИ сильно жмет , Аноним (41), 11:18 , 16-Дек-21, (46) 64 kiB 65 5 kBкиби - 2 10кило - 10 3, Аноним (65), 14:01 , 16-Дек-21, (71) // Не 65 5, а ровно 65 536, Онаним (?), 15:01 , 16-Дек-21, (80) +1 Андроед рутануть даст plug pray, InuYasha (??), 10:16 , 16-Дек-21, (21) +3 Ну подумаешь, выполнение произвольного кода при работе с юсб-устройством Просто, Анонн (?), 10:18 , 16-Дек-21, (22) +1 // Ох еслиб, выпилили лптшки комерсы поганые, Аноним (-), 10:47 , 16-Дек-21, (35) Эта хреновина USB Gadget в обычных потребительских дистрибутивахне используеьс, Аноним (42), 11:07 , 16-Дек-21, (42) ну вот сколько анонимы опеннета им будут повторять, что дырявая сишка их в могил, Аноним (28), 10:28 , 16-Дек-21, (28) –5 // так они и жили дырявая сишка сводила всех в могилу, а потом уставшие, но доволь, Аноним (-), 10:51 , 16-Дек-21, (37) +3 Ох а сколько уязвимостей ещё не обнаружили , User_o0 (?), 12:25 , 16-Дек-21, (60) +1 Еще один бек-дор для СС с служб открыли И их еще много остается , Аноним (73), 14:15 , 16-Дек-21, (73) // ну да, ядро обновил со 190м бинарных вставок и вытер шок с лица, Аноним (81), 15:36 , 16-Дек-21, (81) Webusb из хрома передаёт привет или он не подвержен , Аноним (99), 22:19 , 16-Дек-21, (99) Ну, как обычно , Аноним (116), 05:38 , 17-Дек-21, (116) 1,3,6,21,22,28,60,73,99,116

Сообщения

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

	10. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	–11 +/–
	Сообщение от Аноним (10), 16-Дек-21, 09:56
	а когда кучу надо освободить — это всегда безопасная процедура?
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	–18 +/–
	Сообщение от Брат Анон (ok), 16-Дек-21, 10:05
	На стеке -- да. Но никак не в куче. А вообще, Си доказал давно свою профнепригодность.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+16 +/–
	Сообщение от InuYasha (??), 16-Дек-21, 10:14
	Пока что, лишь Анон доказал давно свою профнепригодность.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	–2 +/–
	Сообщение от Брат Анон (ok), 16-Дек-21, 11:08
	> Пока что, лишь Анон доказал давно свою профнепригодность. При выполнении пары правил (что само по себе не очень идея) -- можно. Си по определению опасен. Я бы его использовать не стал. Оберон -- другое дело.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 11:35
	>Си по определению опасен зарубите на носу и держитесь подальше, ибо язык это не для незнаек и недоучек, я даже не представляю как программисты писали бы на асм.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+5 +/–
	Сообщение от Rev (?), 16-Дек-21, 13:33
	Значит ядро с такими уязвимостями писали знайки и доучки, да?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	–3 +/–
	Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 14:11
	> Значит ядро с такими уязвимостями писали знайки и доучки, да? а ядро причем? никто не запрещает незнайкам и недоучкам писать ядро, а раз в ядре такие же баги, значить их писали незнайки и недоучки. Конечно легче все свалить на дырявую Сишку, а свою безолаберность и некомпетентность не признавать.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+3 +/–
	Сообщение от _ (??), 16-Дек-21, 14:41
	> а ядро причем? никто не запрещает незнайкам и недоучкам писать ядро, а > раз в ядре такие же баги, значить их писали незнайки и недоучки. И рецензировали написанное - тоже незнайки-недоучки, а не сферическо-пряморукие Си-погромизды с опеннета (правда, немного воображаемые), ага. > Конечно легче все свалить на дырявую Сишку, а свою безолаберность и некомпетентность не признавать. То ли дело религиозные адепты, у которых их объект поклонения непогрешим и не подлежит сомнению, а все неурядицы - происки лукавого, испытание, недостаток веры и прочее ...
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	–1 +/–
	Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 17:07
	> И рецензировали написанное - тоже незнайки-недоучки, а не сферическо-пряморукие Си-погромизды > с опеннета (правда, немного воображаемые), ага. выходит так, спросите у того кто проводил рецензию. Не знание тонкостей работы с инструментом не говорит о его "плохости", а лишь подтверждает "незнайности" и "недоучности" пользователя тонкости работы с инструментом. > То ли дело религиозные адепты, у которых их объект поклонения непогрешим и > не подлежит сомнению, а все неурядицы - происки лукавого, испытание, недостаток > веры и прочее ... где тут поклонение, если пользователь не знает всех тонкостей работы с инструментом, его право сменить его, но кричать, ой какой он "плохой" - происки от лукавого.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Прохожий (??), 17-Дек-21, 07:29
	>Не знание тонкостей работы с инструментом не говорит о его "плохости" Если двумя разными инструментами можно сделать одну и ту же работу, только для того, чтобы достичь результата, надо знать тонкости работы первого инструмента, но не надо знать тонкостей работы второго, первый инструмент - хуже. Простая логика.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 17-Дек-21, 11:15
	>Простая логика. Потребительская логика, легче купить продукт.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от амоним (?), 17-Дек-21, 18:11
	легче купить нового раба с нужными знаниями
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	95. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Аноним (95), 16-Дек-21, 20:13
	>> никто не запрещает незнайкам и недоучкам писать ядро А значит ядро нужно писать не на Си. А то незнайки и недоучки делают много ляпов.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	98. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+1 +/–
	Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 21:52
	> А значит ядро нужно писать не на Си. А то незнайки и > недоучки делают много ляпов. отличная логика, незнайка и недоучка по определению не должен писать не на Си ни ядро, раз на то пошло. А если и пишет, ну Бог с ним, я не запрещал :)
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+1 +/–
	Сообщение от искра (?), 17-Дек-21, 04:05
	>ибо язык это не для незнаек и недоучек а кто доучка? практика показвывает, что на си пишут исключительно недоучки, получается. вездеж дыры, значит везде недоучки пишут.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	125. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 17-Дек-21, 11:22
	>а кто доучка? ну а шо поделаешь, если в школе вам будут за место математики преподавать всякую ересь, кто виноват - ученики, которые это хавают? Другое дело когда играет роль чсв, изучая сначала какойто питон, приходят к С, и чсв не позволяет им писать обычный калькулятор, они сразу должны ядро писать, ведь они уже выучили программирование. А если, что-то в процессе идет не так, то фииии С плохой. Хорошо их асм сразу отпугивает :)
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+1 +/–
	Сообщение от Аноним (65), 16-Дек-21, 13:23
	Брат Анон, тебе в ЯОС!
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	100. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от _ (??), 16-Дек-21, 23:44
	Ну а что - тоже хорошие 3 буквы, и означают наверное то-же самое  :)
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Брат Анон (ok), 19-Дек-21, 18:28
	> Брат Анон, тебе в ЯОС! Аноним, ты так это написал, как-будто в этом есть что-то плохое. И тебя сейчас немного рассторю: у меня оно лежит на флешке, я это иногда запускаю побаловаться -- штука офигительная. (Не ЯОС, то что было под ним, в сущности -- тоже самое).
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	23. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Анонм (?), 16-Дек-21, 10:19
	Си еще ладно. Машинные коды вообще никуда не годятся!
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	44. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Брат Анон (ok), 16-Дек-21, 11:09
	> Си еще ладно. > Машинные коды вообще никуда не годятся! Машинные коды не язык. И не переносимо. Хреновая идея.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+2 +/–
	Сообщение от псевдонимус (?), 16-Дек-21, 11:31
	А по мне так отличная. Одна железка -- одна программа, гы. Как у макосексуалистов. Правдо гейось это не спасло: оно все равно оно, что платформа, что ось.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+2 +/–
	Сообщение от InuYasha (??), 16-Дек-21, 17:30
	Полностью согла.. *надменно-осуждающие лица дизайнеров из соседней комнаты* ...сен. *захлопнул дверь*
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от псевдонимус (?), 16-Дек-21, 19:00
	> Полностью согла.. > *надменно-осуждающие лица дизайнеров из соседней комнаты* > ...сен. > *захлопнул дверь* ;)) Но ведь и правда, что нужно: ассемблеры, Фортран, тикль и Шелл. Ну ладно, ц исчо. ) И перл. Для одминов.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от _ (??), 16-Дек-21, 23:49
	и жаба - для индусов и раст - для ****** и пеЙтон - для школоты и ребе - для замороженных и плюсы - чтобы можно было в свитер с оленями ... и брейнфак - потому что это красиво! ВотЪ! (С) :)
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от псевдонимус (?), 16-Дек-21, 19:02
	> Полностью согла.. > *надменно-осуждающие лица дизайнеров из соседней комнаты* > ...сен. > *захлопнул дверь* Мля, япро форт забыл. В принципе достаточно его одного. Лучший язык всех времён и народов, я не шучу
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	102. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от _ (??), 16-Дек-21, 23:51
	Дык все глупости в этом мире сделаны с серьёзным выражение лица! (С) Барон Мюнхгаузен
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 17-Дек-21, 12:02
	не мешайте глупцам совершать глупости (ц) Барон Жером :)
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от InuYasha (??), 17-Дек-21, 12:32
	Бегите, глупцы! (ц) Гендо... т.е. Гендальф :)
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+4 +/–
	Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 11:32
	С доказывает только профнепригодность программистов, которые пишут программы не думая о стеке куче всякой архитектурной хрени
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	110. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Аноним (110), 17-Дек-21, 01:37
	>> С доказывает только профнепригодность программистов, которые пишут программы не думая о стеке куче всякой архитектурной хрени Чтоб об этом думать - надо об этом знать Последних много лет идет снижение порога входа в отрасль А коммит в ядро это строчка в резюме Ревью тоже человеки делают Ну и вот
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 17-Дек-21, 11:29
	>Последних много лет идет снижение порога входа в отрасль ну и к чему приведет снижение этого порога? Можно ли опустить допустим знания приоритетов обычных арифметических действий и заниматься вышматом?
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Аноним (110), 18-Дек-21, 03:26
	>> ну и к чему приведет снижение этого порога? К усилению позиции корпорации-инициатора. Корпорация может себе позволить нанять нормальных. Знающих про процессор, стек, кэш и страницы памяти. И то что они есть и как работают в разных архитектурах. И учитывающих это всё. Остальным достанутся программисты после курсов и соответвенный результат.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Аноним (110), 18-Дек-21, 03:34
	>> Можно ли опустить допустим знания приоритетов обычных арифметических действий и заниматься вышматом? В чужой стране - просто необходимо) Убить системный подход в образовании самый сильный ход наверное. Пообщайтесь с выпускниками школ. Они даже запоминают плохо. Про мышление, тем более критическое, речи не идет.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	140. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 18-Дек-21, 11:16
	>В чужой стране - просто необходимо) план даллеса курит в сторонке, серьезно. >Убить системный подход в образовании самый сильный ход наверное. хотелось бы написать про самообразование, но увы это единицы, и школа решает. >Пообщайтесь с выпускниками школ. Они даже запоминают плохо. Про мышление, тем более критическое, речи не идет. шпаргалки даже нынче не в моде :) гугл в помощь
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+1 +/–
	Сообщение от x3who (?), 16-Дек-21, 12:38
	>  На стеке -- да. Но никак не в куче. Не догоняю в чем разница. Если тебе в стек напишут данные в уже освобождённый буфер по сбежавшему указателю - это разве сильно безопаснее?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	69. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+3 +/–
	Сообщение от n00by (ok), 16-Дек-21, 13:51
	>>  На стеке -- да. Но никак не в куче. > Не догоняю в чем разница. Если тебе в стек напишут данные в > уже освобождённый буфер по сбежавшему указателю - это разве сильно безопаснее? Такая запись не испортит актуальные данные, если не выйдет за границы стека (в ядре ограничен несколькими страницами). Другое дело, что в положенное место запись не прошла, значит там мусор?
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от x3who (?), 17-Дек-21, 12:57
	> Такая запись не испортит актуальные данные, если не выйдет за границы стека > (в ядре ограничен несколькими страницами). Другое дело, что в положенное место > запись не прошла, значит там мусор? Во-первых испортит, если все данные будут храниться на стеке. Во-вторых появляется испортить ещё и как минимум адрес возврата из функции, что вдогонку приведёт к ещё более нехорошим последствиям.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от n00by (ok), 17-Дек-21, 15:00
	Тут надо понимать, что такое вершина стека, которую адресует указатель стека. Обычно путаются, потому что стек растёт в сторону младших адресов (т.е. адрес уменьшается). На самом деле от численных значений можно абстрагироваться: 1. создали локальные: аргумент адрес возврата локальная1 локальная2 локальная3 вершина 2. освободили локальная3: аргумент адрес возврата локальная1 локальная2 вершина локальная3 <- вот сюда пишем по ошибке. Стековый кадр возможно даже не создавать, не менять SP, если внутри подпрограммы нет вызовов. Просто адресуются ячейки над вершиной (а в цифрах их адреса ниже). Подробнее см. red zone в x86-64-psABI-1.0.pdf
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от x3who (?), 18-Дек-21, 10:22
	> вершина > локальная3 <- вот сюда пишем по ошибке. совершенно необязательно, что именно сюда только сюда. И даже что пишем необязательн. По ошибке можно что хошь прчитать или перезаписать. > Обычно путаются, потому что стек растёт в сторону младших адресов (т.е. адрес уменьшается). ну и что? вот разместил ты на стеке буфер и пишешь в него. По возрастанию адресов. Буфер кончился, а ты по ошибке продолжаешь в него писать. Такую ошибку легко вообразить. И будешь ты переписывать данные и адреса возвратов. Не вижу чем это лучше динамического выделения памяти ппи котором хоть адреса возврата уцелеют если что.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от n00by (ok), 18-Дек-21, 11:16
	>> вершина >> локальная3 <- вот сюда пишем по ошибке. > совершенно необязательно, что именно сюда только сюда. И даже что пишем необязательн. > По ошибке можно что хошь прчитать или перезаписать. Желательно помнить контекст: #10 >>> а когда кучу надо освободить — это всегда безопасная процедура? #15 >> На стеке -- да. Но никак не в куче. #61 > Не догоняю в чем разница. Если тебе в стек напишут данные #61 > в уже освобождённый буфер по сбежавшему указателю - это разве сильно безопаснее? освобождённый на стеке - всегда после вершины >> Обычно путаются, потому что стек растёт в сторону младших адресов (т.е. адрес уменьшается). > ну и что? вот разместил ты на стеке буфер и пишешь в > него. По возрастанию адресов. Буфер кончился, а ты по ошибке продолжаешь > в него писать. Такую ошибку легко вообразить. И будешь ты переписывать > данные и адреса возвратов. Не вижу чем это лучше динамического выделения > памяти ппи котором хоть адреса возврата уцелеют если что. Этот буфер не освобождён и ошибка другая.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от x3who (?), 18-Дек-21, 12:30
	> освобождённый на стеке - всегда после вершины Не всегда. Вот пример: какой-то код фызвал функцию, которая разместила буфер на стеке, пошаманила там что-то и вернула некую структуру в которой одно из полей содержит указатель на этот буфер. Вызывающий код про эту структуру даже не курсе, он просто передаёт её как параметр другой функции и та вдруг осуществляет доступ по переданному указателю куда-то себе в стек, где лежат уже другие данные. > Этот буфер не освобождён и ошибка другая. желательно помнить контекст - тема про переполнение буфера, так что ошибка будет сабжевая
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от n00by (ok), 18-Дек-21, 13:38
	>> освобождённый на стеке - всегда после вершины > Не всегда. Это следует из определения. Цитирую System V Application Binary Interface AMD64 Architecture Processor Supplement 3.2.2 The Stack Frame The stack pointer, %rsp, always points to the end of the latest allocated stack frame. > Вот пример: какой-то код фызвал функцию, которая разместила буфер на > стеке, пошаманила там что-то и вернула некую структуру в которой одно > из полей содержит указатель на этот буфер. В данный момент буфер в стеке освобождён, записи пока нет. > Вызывающий код про эту структуру даже не курсе, он просто передаёт её > как параметр другой функции и та вдруг осуществляет доступ по переданному > указателю куда-то себе в стек, где лежат уже другие данные. Здесь стек уже занят (под другой буфер). Спасибо, теперь понятно, где я ошибся. В вопросах фигурировало "всегда" и мне следовало бы конкретизировать "в пределах функции", что бы не возникло разночтений. Я понял "уже освобождённый" как "только что освобождённый". Вот такой код может уронить приложение, поскольку страница вернулась системе: free(p); if (*p); >> Этот буфер не освобождён и ошибка другая. > желательно помнить контекст - тема про переполнение буфера, так что ошибка будет > сабжевая Тему сменили на обсуждение использования после освобождения, и я отвечал на вполне конкретный вопрос про освобождённый стек. Размер записанных данных в вопросе не оговаривается, потому я его вывел из условия "освобождённый" - то есть не пересекает вершину.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от x3who (?), 18-Дек-21, 15:20
	> Вот такой код может уронить приложение, поскольку страница вернулась системе: > free(p); > if (*p); Не должен бы. Не знаю, но подозреваю, что кернельские треды уже имеют преаллоцированные стеки. Стеки юзерских процессов судя по наличию функции expand_stack() и отсутствию обратной ( https://github.com/torvalds/linux/blob/master/include/linux/... ) - только растут. Ну и по смыслу на каждое подергивание стека ходить в ядро и освобождать страницы - это очень дорогая операция. Кроме того, даже если ваша программа обратится в произвольную часть стека в пределах лимита на размер стека и там не окажется страницы то никто никуда не упадёт: возникнет исключение в котором ядро скорее всего тупо подложит страницу под ту область куда произошло обращение. > Тему сменили на обсуждение использования после освобождения, и я отвечал на вполне > конкретный вопрос про освобождённый стек. Размер записанных данных в вопросе не > оговаривается, потому я его вывел из условия "освобождённый" - то есть > не пересекает вершину. Ну я просто например не понял, почему там народ решил, что освобождение памяти в куче чем-то опаснее чем стек, потому и спрашивал.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от n00by (ok), 18-Дек-21, 17:21
	>> Вот такой код может уронить приложение, поскольку страница вернулась системе: >> free(p); >> if (*p); > Не должен бы. Если освобождаемый блок окажется последним занятым в странице памяти, менеджер кучи может решить вернуть страницу системе и выполнит munmap(). Таким образом адресуемая указателем память окажется недоступна. Самое весёлое, когда подобное совпадение происходит в 1 случае из 100000. > Не знаю, но подозреваю, что кернельские треды уже имеют > преаллоцированные стеки. Писал о них в #74. Размер 8К. > Стеки юзерских процессов судя по наличию функции expand_stack() > и отсутствию обратной ( https://github.com/torvalds/linux/blob/master/include/linux/... > ) - только растут. Ну и по смыслу на каждое подергивание > стека ходить в ядро и освобождать страницы - это очень дорогая > операция. Так free() это не стек. В куче предполагается хранить большие объёмы, а в стеке малые - потому в куче разумно предусмотреть возврат страниц системе, а в стеке они лишний. > Кроме того, даже если ваша программа обратится в произвольную часть > стека в пределах лимита на размер стека и там не окажется > страницы то никто никуда не упадёт: возникнет исключение в котором ядро > скорее всего тупо подложит страницу под ту область куда произошло обращение. >> Тему сменили на обсуждение использования после освобождения, и я отвечал на вполне >> конкретный вопрос про освобождённый стек. Размер записанных данных в вопросе не >> оговаривается, потому я его вывел из условия "освобождённый" - то есть >> не пересекает вершину. > Ну я просто например не понял, почему там народ решил, что освобождение > памяти в куче чем-то опаснее чем стек, потому и спрашивал. Наверное, потому что аллоцировать на куче и сохранять указатель - обычная операция (другое дело, что потом с ним работа некорректна). А сохранять указатель на стековые данные - необычная. То есть стек используется как кратковременное хранилище, в таком сценарии перезапись свободной его части безопасна. P.S. капча 66666 >*-)
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	147. Скрыто модератором	+/–
	Сообщение от Аноним (-), 23-Дек-21, 08:28
	> На стеке -- да. Но никак не в куче. А вообще, Си доказал давно свою профнепригодность. Проблема в том что другие пока не доказали свою провпригодность и быкуют из операционок писаных на сях, гадясь под себя :)
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	16. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Корец (?), 16-Дек-21, 10:06
	Да, если с освобождаемой памятью закончена работа и к ней больше не обращаться.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	41. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от Аноним (41), 16-Дек-21, 11:07
	> а когда кучу надо освободить — это всегда безопасная процедура? Да. Как можно не знать таких основ (азов, элементарщины)! Нельзя обращаться к освобождённой куче.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	70. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."	+/–
	Сообщение от n00by (ok), 16-Дек-21, 13:55
	>> а когда кучу надо освободить — это всегда безопасная процедура? > Да. > Как можно не знать таких основ (азов, элементарщины)! > Нельзя обращаться к освобождённой куче. Если нельзя, но очень хочется реализовать сборку мусора по алгоритму mark-compact, то можно.
	Ответить | Правка | Наверх | Cообщить модератору

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

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