В USB Gadget, подсистеме ядра Linux, предоставляющей программный интерфейс для создания клиентских USB-устройств и программной симуляции USB-устройств, выявлена уязвимость (CVE-2021-39685), которая может привести к утечке информации из ядра, краху или выполнению произвольного кода на уровне ядра. Атака производится непривилегированным локальным пользователем через манипуляции с различными классами устройств, реализованными на базе API USB Gadget, такими, как rndis, hid, uac1, uac1_legacy и uac2...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56357
Да блин. Опять все из за Сей, с их буфферами ограниченного размера, создаваемыми на стеке. Сейчас 21-й век. Ну юзайте, блин, динамически выделяемые буфферы.
На сях можно выделить память на куче и работать с ней. При чём тут си? Тут ошибка в логике.
а когда кучу надо освободить — это всегда безопасная процедура?
На стеке -- да. Но никак не в куче. А вообще, Си доказал давно свою профнепригодность.
Пока что, лишь Анон доказал давно свою профнепригодность.
> Пока что, лишь Анон доказал давно свою профнепригодность.При выполнении пары правил (что само по себе не очень идея) -- можно.
Си по определению опасен. Я бы его использовать не стал. Оберон -- другое дело.
>Си по определению опасензарубите на носу и держитесь подальше, ибо язык это не для незнаек и недоучек, я даже не представляю как программисты писали бы на асм.
Значит ядро с такими уязвимостями писали знайки и доучки, да?
> Значит ядро с такими уязвимостями писали знайки и доучки, да?а ядро причем? никто не запрещает незнайкам и недоучкам писать ядро, а раз в ядре такие же баги, значить их писали незнайки и недоучки. Конечно легче все свалить на дырявую Сишку, а свою безолаберность и некомпетентность не признавать.
> а ядро причем? никто не запрещает незнайкам и недоучкам писать ядро, а
> раз в ядре такие же баги, значить их писали незнайки и недоучки.И рецензировали написанное - тоже незнайки-недоучки, а не сферическо-пряморукие Си-погромизды с опеннета (правда, немного воображаемые), ага.
> Конечно легче все свалить на дырявую Сишку, а свою безолаберность и некомпетентность не признавать.То ли дело религиозные адепты, у которых их объект поклонения непогрешим и не подлежит сомнению, а все неурядицы - происки лукавого, испытание, недостаток веры и прочее ...
> И рецензировали написанное - тоже незнайки-недоучки, а не сферическо-пряморукие Си-погромизды
> с опеннета (правда, немного воображаемые), ага.выходит так, спросите у того кто проводил рецензию. Не знание тонкостей работы с инструментом не говорит о его "плохости", а лишь подтверждает "незнайности" и "недоучности" пользователя тонкости работы с инструментом.
> То ли дело религиозные адепты, у которых их объект поклонения непогрешим и
> не подлежит сомнению, а все неурядицы - происки лукавого, испытание, недостаток
> веры и прочее ...где тут поклонение, если пользователь не знает всех тонкостей работы с инструментом, его право сменить его, но кричать, ой какой он "плохой" - происки от лукавого.
>Не знание тонкостей работы с инструментом не говорит о его "плохости"Если двумя разными инструментами можно сделать одну и ту же работу, только для того, чтобы достичь результата, надо знать тонкости работы первого инструмента, но не надо знать тонкостей работы второго, первый инструмент - хуже. Простая логика.
>Простая логика.Потребительская логика, легче купить продукт.
легче купить нового раба с нужными знаниями
>> никто не запрещает незнайкам и недоучкам писать ядроА значит ядро нужно писать не на Си. А то незнайки и недоучки делают много ляпов.
> А значит ядро нужно писать не на Си. А то незнайки и
> недоучки делают много ляпов.отличная логика, незнайка и недоучка по определению не должен писать не на Си ни ядро, раз на то пошло. А если и пишет, ну Бог с ним, я не запрещал :)
>ибо язык это не для незнаек и недоучека кто доучка? практика показвывает, что на си пишут исключительно недоучки, получается. вездеж дыры, значит везде недоучки пишут.
>а кто доучка?ну а шо поделаешь, если в школе вам будут за место математики преподавать всякую ересь, кто виноват - ученики, которые это хавают? Другое дело когда играет роль чсв, изучая сначала какойто питон, приходят к С, и чсв не позволяет им писать обычный калькулятор, они сразу должны ядро писать, ведь они уже выучили программирование. А если, что-то в процессе идет не так, то фииии С плохой. Хорошо их асм сразу отпугивает :)
Брат Анон, тебе в ЯОС!
Ну а что - тоже хорошие 3 буквы, и означают наверное то-же самое :)
> Брат Анон, тебе в ЯОС!Аноним, ты так это написал, как-будто в этом есть что-то плохое. И тебя сейчас немного рассторю: у меня оно лежит на флешке, я это иногда запускаю побаловаться -- штука офигительная. (Не ЯОС, то что было под ним, в сущности -- тоже самое).
Си еще ладно.
Машинные коды вообще никуда не годятся!
> Си еще ладно.
> Машинные коды вообще никуда не годятся!Машинные коды не язык. И не переносимо. Хреновая идея.
А по мне так отличная. Одна железка -- одна программа, гы. Как у макосексуалистов. Правдо гейось это не спасло: оно все равно оно, что платформа, что ось.
Полностью согла..
*надменно-осуждающие лица дизайнеров из соседней комнаты*
...сен.
*захлопнул дверь*
> Полностью согла..
> *надменно-осуждающие лица дизайнеров из соседней комнаты*
> ...сен.
> *захлопнул дверь*;))
Но ведь и правда, что нужно: ассемблеры, Фортран, тикль и Шелл. Ну ладно, ц исчо. ) И перл. Для одминов.
и жаба - для индусов
и раст - для ******
и пеЙтон - для школоты
и ребе - для замороженных
и плюсы - чтобы можно было в свитер с оленями
...
и брейнфак - потому что это красиво!ВотЪ! (С) :)
> Полностью согла..
> *надменно-осуждающие лица дизайнеров из соседней комнаты*
> ...сен.
> *захлопнул дверь*Мля, япро форт забыл. В принципе достаточно его одного. Лучший язык всех времён и народов, я не шучу
Дык все глупости в этом мире сделаны с серьёзным выражение лица! (С) Барон Мюнхгаузен
не мешайте глупцам совершать глупости (ц) Барон Жером :)
Бегите, глупцы! (ц) Гендо... т.е. Гендальф :)
С доказывает только профнепригодность программистов, которые пишут программы не думая о стеке куче всякой архитектурной хрени
>> С доказывает только профнепригодность программистов, которые пишут программы не думая о стеке куче всякой архитектурной хрениЧтоб об этом думать - надо об этом знать
Последних много лет идет снижение порога входа в отрасль
А коммит в ядро это строчка в резюме
Ревью тоже человеки делают
Ну и вот
>Последних много лет идет снижение порога входа в отрасльну и к чему приведет снижение этого порога? Можно ли опустить допустим знания приоритетов обычных арифметических действий и заниматься вышматом?
>> ну и к чему приведет снижение этого порога?К усилению позиции корпорации-инициатора.
Корпорация может себе позволить нанять нормальных. Знающих про процессор, стек, кэш и страницы памяти. И то что они есть и как работают в разных архитектурах. И учитывающих это всё.
Остальным достанутся программисты после курсов и соответвенный результат.
>> Можно ли опустить допустим знания приоритетов обычных арифметических действий и заниматься вышматом?В чужой стране - просто необходимо)
Убить системный подход в образовании самый сильный ход наверное.
Пообщайтесь с выпускниками школ. Они даже запоминают плохо. Про мышление, тем более критическое, речи не идет.
>В чужой стране - просто необходимо)план даллеса курит в сторонке, серьезно.
>Убить системный подход в образовании самый сильный ход наверное.
хотелось бы написать про самообразование, но увы это единицы, и школа решает.
>Пообщайтесь с выпускниками школ. Они даже запоминают плохо. Про мышление, тем более критическое, речи не идет.
шпаргалки даже нынче не в моде :) гугл в помощь
> На стеке -- да. Но никак не в куче.Не догоняю в чем разница. Если тебе в стек напишут данные в уже освобождённый буфер по сбежавшему указателю - это разве сильно безопаснее?
>> На стеке -- да. Но никак не в куче.
> Не догоняю в чем разница. Если тебе в стек напишут данные в
> уже освобождённый буфер по сбежавшему указателю - это разве сильно безопаснее?Такая запись не испортит актуальные данные, если не выйдет за границы стека (в ядре ограничен несколькими страницами). Другое дело, что в положенное место запись не прошла, значит там мусор?
> Такая запись не испортит актуальные данные, если не выйдет за границы стека
> (в ядре ограничен несколькими страницами). Другое дело, что в положенное место
> запись не прошла, значит там мусор?Во-первых испортит, если все данные будут храниться на стеке. Во-вторых появляется испортить ещё и как минимум адрес возврата из функции, что вдогонку приведёт к ещё более нехорошим последствиям.
Тут надо понимать, что такое вершина стека, которую адресует указатель стека. Обычно путаются, потому что стек растёт в сторону младших адресов (т.е. адрес уменьшается). На самом деле от численных значений можно абстрагироваться:1. создали локальные:
аргумент
адрес возврата
локальная1
локальная2
локальная3
вершина2. освободили локальная3:
аргумент
адрес возврата
локальная1
локальная2
вершина
локальная3 <- вот сюда пишем по ошибке.Стековый кадр возможно даже не создавать, не менять SP, если внутри подпрограммы нет вызовов. Просто адресуются ячейки над вершиной (а в цифрах их адреса ниже). Подробнее см. red zone в x86-64-psABI-1.0.pdf
> вершина
> локальная3 <- вот сюда пишем по ошибке.совершенно необязательно, что именно сюда только сюда. И даже что пишем необязательн. По ошибке можно что хошь прчитать или перезаписать.
> Обычно путаются, потому что стек растёт в сторону младших адресов (т.е. адрес уменьшается).ну и что? вот разместил ты на стеке буфер и пишешь в него. По возрастанию адресов. Буфер кончился, а ты по ошибке продолжаешь в него писать. Такую ошибку легко вообразить. И будешь ты переписывать данные и адреса возвратов. Не вижу чем это лучше динамического выделения памяти ппи котором хоть адреса возврата уцелеют если что.
>> вершина
>> локальная3 <- вот сюда пишем по ошибке.
> совершенно необязательно, что именно сюда только сюда. И даже что пишем необязательн.
> По ошибке можно что хошь прчитать или перезаписать.Желательно помнить контекст:
#10 >>> а когда кучу надо освободить — это всегда безопасная процедура?
#15 >> На стеке -- да. Но никак не в куче.
#61 > Не догоняю в чем разница. Если тебе в стек напишут данные
#61 > в уже освобождённый буфер по сбежавшему указателю - это разве сильно безопаснее?освобождённый на стеке - всегда после вершины
>> Обычно путаются, потому что стек растёт в сторону младших адресов (т.е. адрес уменьшается).
> ну и что? вот разместил ты на стеке буфер и пишешь в
> него. По возрастанию адресов. Буфер кончился, а ты по ошибке продолжаешь
> в него писать. Такую ошибку легко вообразить. И будешь ты переписывать
> данные и адреса возвратов. Не вижу чем это лучше динамического выделения
> памяти ппи котором хоть адреса возврата уцелеют если что.Этот буфер не освобождён и ошибка другая.
> освобождённый на стеке - всегда после вершиныНе всегда. Вот пример: какой-то код фызвал функцию, которая разместила буфер на стеке, пошаманила там что-то и вернула некую структуру в которой одно из полей содержит указатель на этот буфер.
Вызывающий код про эту структуру даже не курсе, он просто передаёт её как параметр другой функции и та вдруг осуществляет доступ по переданному указателю куда-то себе в стек, где лежат уже другие данные.> Этот буфер не освобождён и ошибка другая.
желательно помнить контекст - тема про переполнение буфера, так что ошибка будет сабжевая
>> освобождённый на стеке - всегда после вершины
> Не всегда.Это следует из определения. Цитирую 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);>> Этот буфер не освобождён и ошибка другая.
> желательно помнить контекст - тема про переполнение буфера, так что ошибка будет
> сабжеваяТему сменили на обсуждение использования после освобождения, и я отвечал на вполне конкретный вопрос про освобождённый стек. Размер записанных данных в вопросе не оговаривается, потому я его вывел из условия "освобождённый" - то есть не пересекает вершину.
> Вот такой код может уронить приложение, поскольку страница вернулась системе:
> free(p);
> if (*p);Не должен бы. Не знаю, но подозреваю, что кернельские треды уже имеют преаллоцированные стеки. Стеки юзерских процессов судя по наличию функции expand_stack() и отсутствию обратной ( https://github.com/torvalds/linux/blob/master/include/linux/... ) - только растут. Ну и по смыслу на каждое подергивание стека ходить в ядро и освобождать страницы - это очень дорогая операция. Кроме того, даже если ваша программа обратится в произвольную часть стека в пределах лимита на размер стека и там не окажется страницы то никто никуда не упадёт: возникнет исключение в котором ядро скорее всего тупо подложит страницу под ту область куда произошло обращение.
> Тему сменили на обсуждение использования после освобождения, и я отвечал на вполне
> конкретный вопрос про освобождённый стек. Размер записанных данных в вопросе не
> оговаривается, потому я его вывел из условия "освобождённый" - то есть
> не пересекает вершину.Ну я просто например не понял, почему там народ решил, что освобождение памяти в куче чем-то опаснее чем стек, потому и спрашивал.
>> Вот такой код может уронить приложение, поскольку страница вернулась системе:
>> free(p);
>> if (*p);
> Не должен бы.Если освобождаемый блок окажется последним занятым в странице памяти, менеджер кучи может решить вернуть страницу системе и выполнит munmap(). Таким образом адресуемая указателем память окажется недоступна. Самое весёлое, когда подобное совпадение происходит в 1 случае из 100000.
> Не знаю, но подозреваю, что кернельские треды уже имеют
> преаллоцированные стеки.Писал о них в #74. Размер 8К.
> Стеки юзерских процессов судя по наличию функции expand_stack()
> и отсутствию обратной ( https://github.com/torvalds/linux/blob/master/include/linux/...
> ) - только растут. Ну и по смыслу на каждое подергивание
> стека ходить в ядро и освобождать страницы - это очень дорогая
> операция.Так free() это не стек. В куче предполагается хранить большие объёмы, а в стеке малые - потому в куче разумно предусмотреть возврат страниц системе, а в стеке они лишний.
> Кроме того, даже если ваша программа обратится в произвольную часть
> стека в пределах лимита на размер стека и там не окажется
> страницы то никто никуда не упадёт: возникнет исключение в котором ядро
> скорее всего тупо подложит страницу под ту область куда произошло обращение.
>> Тему сменили на обсуждение использования после освобождения, и я отвечал на вполне
>> конкретный вопрос про освобождённый стек. Размер записанных данных в вопросе не
>> оговаривается, потому я его вывел из условия "освобождённый" - то есть
>> не пересекает вершину.
> Ну я просто например не понял, почему там народ решил, что освобождение
> памяти в куче чем-то опаснее чем стек, потому и спрашивал.Наверное, потому что аллоцировать на куче и сохранять указатель - обычная операция (другое дело, что потом с ним работа некорректна). А сохранять указатель на стековые данные - необычная. То есть стек используется как кратковременное хранилище, в таком сценарии перезапись свободной его части безопасна.
P.S. капча 66666 >*-)
> На стеке -- да. Но никак не в куче. А вообще, Си доказал давно свою профнепригодность.Проблема в том что другие пока не доказали свою провпригодность и быкуют из операционок писаных на сях, гадясь под себя :)
Да, если с освобождаемой памятью закончена работа и к ней больше не обращаться.
> а когда кучу надо освободить — это всегда безопасная процедура?Да.
Как можно не знать таких основ (азов, элементарщины)!Нельзя обращаться к освобождённой куче.
>> а когда кучу надо освободить — это всегда безопасная процедура?
> Да.
> Как можно не знать таких основ (азов, элементарщины)!
> Нельзя обращаться к освобождённой куче.Если нельзя, но очень хочется реализовать сборку мусора по алгоритму mark-compact, то можно.
Проблема в том, что при обращении за пределы "своей" памяти по умолчанию происходит... абсолютно ничего! Порти чужую память как хочешь, ты же знаешь что делаешь!
Это нужно включать всякие защиты в виде доп.опций компиляции чтобы оно начинало проверять и ругаться. И конечно оно выключено по умолчанию.
Какая "своя память", "чужая память".
Это ядро и ring0, так-то.
Можно это аргументировать так, что куча медленная, но можно же сделать что то типа пулла буферов. Не? Тут смысл просто в том, чтобы не было этого искусственного ограничения из за создания константного массива на стеке, хотя стек в принципе можно тоже выделять и динамически. И чтобы данные не валялись рядом с адресами возврата, которые можно попортить переполнением.
>куча медленнаяПервый раз слышу. Расскажи подробнее.
Как работает стек:
SUB RSP, 10HКак работает куча:
Найти свободный блок
Выделить свободный блокСтек всегда можно тоже выделять динамически, просто об этом мало кто знает:
//Предполагается fastcall, размер в rax
AllocStack proc
pop rdx
sud rsp, rax
jmp rdx
endp
В х..якс интелбои недоделанные. реализация кучи для усера это malloc в libc, sbrk в ведре и тд . стеки оно попает каком-то говноасме неправославном
Ну да. А malloc за счет духа святого работает. Вот и выросло поколение, которое думает, что выделение памяти - это бесплатная операция. А ведь когда то в давние времена все данные были статичным, в том числе и объекты, именно потому, что это далеко не так.
> А malloc за счет духа святого работает.в сообщении выше так и сказано. динамической памятью занимается операционная система.
> в давние времена все данные были статичным, в том числе и объекты
т.е ты предлагаешь начать растягивать стек ? ты или ни..я не понимаешь о чем говоришь, либо мосок решил повыносить, но скорее первое.
В рылотайме оно то сих пор не так, программирование его на древних процессорах вправляет мозги.
Собственно никто не заставляет использовать динамическое выделение памяти в своих программах. Но есть нюанс, размер стека не резиновый, и если вы хотите 100 мегов - в стеке их элементарно не окажется. Более того, вы об этом узнаете довольно неприятным способом. Каким именно? А закажите себе VLA покрупнее, как раз и узнаете почему их не любят.
И да. По мне так AT&T не православный асм, ибо куча знаков препинания ненужных.
Злодеи они, запретили man alloca. Впрочем, правильно сделали.
если не понимаешь о чем речь - проходи мимо, не позорься
А о чём речь? sbrk в ядре? Азазазаза. https://www.kernel.org/doc/htmldocs/kernel-api/mm.html
сейчас до тебя дойдет что это работа памятью в кернелспейсе ... продолжай перебор, может докопаеш к вечеру
Работа с памятью в, цитирую новость: подсистеме ядра Linux, происходит в кернелспейсе?! Какая неожиданность. Я думал, ядро - это то, на чём Мюнхгаузен летал в земли юзеров.
man alloca, Аноним.
Может не будем языком молоть и просто проведем тест?Скажем миллион раз сделаем malloc и free.
Миллион раз сделаем sub rsp, x и add rsp, x.Потом сравним результаты.
Аноним настолько туп, что не может отличить "alloca" от "malloc"?Аноним НАСТОЛЬКО туп, что допускает неспособность оппонента отличить вызов функции от инкремента/декремента регистра?
Аноним, небось, еще и поклонник раста? Я угадал?
1. Ты забыл про путешествия в ядро за физическими страницами памяти, что для стека что для кучи. Это очень медленно и при этом куча умеет эти страницы придерживать для переиспользования.2. На стеке ты сильно много данных не разместишь, дефолтный ulimit 8Мб, ну можно его раздвинуть, но тоже несравнимо с адресным пространством данных
>[оверквотинг удален]
> Как работает куча:
> Найти свободный блок
> Выделить свободный блок
> Стек всегда можно тоже выделять динамически, просто об этом мало кто знает:
> //Предполагается fastcall, размер в rax
> AllocStack proc
> pop rdx
> sud rsp, rax
> jmp rdx
> endpКак и об этом:
x86_64 page size (PAGE_SIZE) is 4K.
Like all other architectures, x86_64 has a kernel stack for every
active thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big
https://www.kernel.org/doc/Documentation/x86/kernel-stacks> pop rdx
> sud rsp, rax
> jmp rdxТак делать не рекомендуется из соображений производительности. Да и прикиньте размеры опкодов - их экономичнее встроить вместо call.
Можно, и даже уже сделано - в ядре есть и разные slab/slub аллокаторы, и kmalloc и чего только нет. Но в данном случае программист выделил буфер на стеке, потому-что выделять через аллокаторы дороже (на стеке это буквально несколько команд, а всё остальное это вызовы функций и беготня по другим подсистемам ядра).
да кстати, пацаны, почему каждая либа изобретает свой собственный менеджер памяти? в libxml2 есть какой-то собственный xmlBuf, а у xerces там вообще страшно смотреть на ихнее дерево классов, посвященное только управлению памяти. Почему нельзя догадаться сделать какой-нибудь libmem, который будет это все делать правильно и унифицировано?
Можно. Разрешаю.
> который будет это все делать правильно и унифицированопотому что "правильно и унифицированно" не существует. хоть и сказочки корпорастов твердят обратное, а неокрепшие растишки так и тянутся к сказочкам, чтобы потом корпорастики их скушали за обедом мвахахаха
> да кстати, пацаны, почему каждая либа изобретает свой собственный менеджер памятишоп на выхаде ты такой стоя спиной к эффектному взрыву говоришь - free(xmlBuf) , и уходишь за фокус камеры, можно еще фак в сторону мелкософтного жималока показать
Так уже один ржавый язык придумал, так теперь огромная пачка олдфагов ходит и пердит в каждом топике о ненужности.С другой стороны зачем библиотеку делать это должно быть частью языка: строки, списки, хеши и т.д. в том числе и буферы.
Вообще переработать apr и воткнуть в стандарт C22
Очередной растишечка расписался в профнепригодности.
ахаха, это пять.
Это он сгоряча, он просто маны на unsafe на раст не читал.
В ядре?
Ну ладно, указанный случай ещё терпимо.
Но вот пожелаю вам в обработчиках прерываний всю жизнь динамически буферы выделять.
Ты когда молотком по пальцу попадаешь, это молоток виноват или это ты криворукий придурок?
Есть автоматизированные молотки. Там тяжело, если вообще возможно, по пальцу попасть. Так что - да, если молотком можно попасть по пальцу - это плохой молоток.
> Есть автоматизированные молотки. Там тяжело, если вообще возможно, по пальцу попасть. Так
> что - да, если молотком можно попасть по пальцу - это
> плохой молоток.Ну может по пальцу не попасть, а уж гвоздь в лоб забить то точно можно. У нас придурки с выдумкой. Они или автоматический молоток сломают или покалечатся. Так что не поможет придурку автоматический молоток, как показывает практика.
https://www.youtube.com/watch?v=xA7W1vxYYlE
там ещё продолжение есть, можно посмотреть на результат с 1:20 https://www.youtube.com/watch?v=vfUZVyBlca0
А придурок тот, кто этого не понимает.
> А придурок тот, кто этого не понимает.Не, придурок тот, кто думает, что автоматика за него всё сделает, а он только кнопочку нажмёт.
Так его как раз и уволят - кнопку так то и робот жать может, да и кнопку можно убрать, роботу она ни к чему.
> Так его как раз и уволят - кнопку так то и робот
> жать может, да и кнопку можно убрать, роботу она ни к
> чему.Именно так :-) Сейчас нейросети научат растоманить и все "безопасные программисты" пойдут на мороз ;-)
Потом от вашей динамической памяти страдают целые сервера.
программировать нормально надо, а не задним местом!!
А ошибки в коде - это нормально, люди ведь пишут, и находят и исправляют. Так мы и эволюционируем, из обезьяны в профессионалы.
Пока ядро не переведут на более адекватные языки - оно так и будет рассадником дыр
Я даже знаю, какой адекватный язык вы имеете ввиду
Догадаться нетрудно
Ты на нем попробуй напищи чего-нить... там что не действие то боль сплошная. А в сях ращбереться даже карапуз
Ахахаха, это пять)
Покажи свои проекты на расте, чудик? Ты вообще видел шоу с поддержкой раста в ядре? Там куда ни ткни, подпорки и костыли, в найтли уже почти работает, но у нас там косяк с архитектурой либы и рантайма вышел, мы работаем над этим!!!111А пакамест проапдейтите сборку окислов запуском неподписаного шелскриптика с хз какого сайта вот. Безопасность.
Вот карапузы и ваяют эти уязвимости как раз :))
Не смог разобраться в Расте - не лезь в ядро. Так должно быть.
> Не смог разобраться в Расте - не лезь в ядро. Так должно быть.Не смог осилить элементарный C не лезь вообще никуда. Улицы убирай, срачь кругом.
> Не смог осилить элементарный C не лезь вообще никуда. Улицы убирай, срачь кругом.https://www.misra.org.uk/misra-c/
https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Cod...
> SEI CERT C Coding StandardСпрячь смарт, перерыв окончен - еще две улицы не убраны.
Предлагаешь всем без исключения программистам на сишке пойти мести улицы? какая жестокость
А ядро тебе кто будет тогда патчить, чтобы ты тут мог умные коменты строчить?
точно! этот язык — D
Кстати, интересный язык. Всё хочу на нём свой пакетный менеджер переписать.
вот о чем я говорил, калькулятор вменяемый сначала напишите, а дальше хоть ядро :)
Ты на нем хоть что-нибудь написать смог? Синтаксис у него больно уж... кислотненький :)
В каком смысле? Там же вроде питоноподобный синтаксис?
Да все знают.
Нет ядра - нет дыр.
На яваскрипт, что ли?
пф хуже этой солянки даже не знаю что сыскать, разве что c++/golang/rust
Что в этом списке делает golang? Тонны годного софта на нём. И не падает.
тонко, особенно про годный :D
> тонко, особенно про годный :DВ каждой шутке -- лишь доля шутки. Всё остальное правда.
> доляпочти не падает растяжимое понятие, раз в час это тоже почти.
Главное заставить других верить в эту правду, да?
- Тут 12309 опять вернулся.
- Да врёте вы всё, это сборка мусора в ядре.
проснись, соня, уже давно. почему не пользуешься? а дистриб почему не сделал?https://bellard.org/jslinux/
https://retrage.github.io/lkl-js/
ЕСЛИ дыра_в_ядре РАВНО ЕСТЬ!
НЦ
ПЕЧАТЬ кавычка Обноружена дыра в ядре!!! кавычка
КЦ
Будяк Д.В, перелогиньтесь
какие адекватные?
C#, Java, Python или любой другой язык с управлением памятью
"Иди ты на фиг, прерываеие реального времени, у меня тут GC работает, не до тебя сейчас".
>> RTSJ / Java RTS Sun
> "Иди ты на фиг, прерываеие реального времени, у меня тут GC работает, не до тебя сейчас".И слышавшие звон/опоздавшие родиться - пусть идут туда же.
Эвон чего откопали. Как у него с оверхэдом было? Как у обычной явы, я полагаю. С работой не внутри какого-нибудь Websphere, а прямо поверх железа, как и положено операционке? Точно так же. Хоть одно обновление за 15 лет? Тоже все плохо. Про аналоги для C# и (прастихоспади) питона даже спрашивать страшно.
> Эвон чего откопали. Как у него с оверхэдом было? Как у обычнойЗанятный спрыг с темы. Опеннетно-классический.
> Про аналоги для C# и (прастихоспади) питона даже спрашивать страшно.Ну, запретить опеннетчикам писать глупости я не могу, так что ... крепитесь там!
Т.е. по теме аргументов нет, кроме "сам дурак"? Ок, ясно-понятно.
> Т.е. по теме аргументов нет, кроме "сам дурак"?Т.е. ты сам шутсро спрыгнул с темы "Иди ты на фиг, прерываеие реального времени, у меня тут GC работает, не до тебя сейчас", зато ожидал каких-то аргументов по теме твоего спрыга?
> Ок, ясно-понятно.Рад за тебя.
Прерывания. С 10x оверхедом. С динамическим выделением памяти. С кеш-промахами во все поля. Я правда не знаю, как это серьезно обсуждать.
===
Memory ManagementGarbage-collected memory heaps have always been considered an obstacle to real-time programming due to the unpredictable latencies introduced by the garbage collector. The RTSJ addresses this issue by providing several extensions to the memory model, which support memory management in a manner that does not interfere with the ability of real-time code to provide deterministic behavior. This goal is accomplished by allowing the allocation of objects outside of the garbage-collected heap for both short-lived and long-lived objects.
===
> Прерывания. С 10x оверхедом. С динамическим выделением памяти. С кеш-промахами во все поля.
> Я правда не знаю, как это серьезно обсуждать.Я тоже не знаю, зачем обсуждать фантазии анонима.
Да, мне тоже пришлось это прочитать, когда вы упомянули RTSJ. Да, они (частично) избавились от gc lock. А теперь объясните, ради бога, куда делись остальные причины, которые делают этот RTSJ провалившимся академическим экспериментом, непригодным для решения заявленой в заголовке новости проблемы.
>до 65 КБт.е. до 64 КБ включительно, т е. просто 64 КБ, а не почему то 65 КБ?
Акция! 1 Кб в подарок!
Ага. Это как во времена AT. Купи 640Кб, 65520 в подарок.
Нет.
До 65 КБ - это 64 КБ плюс 1023 байт (999 если СИ сильно жмет)
64 kiB ~ 65.5 kB
киби - 2^10
кило - 10^3
Не ~65.5, а ровно 65.536
Андроед рутануть даст? plug & pray
Ну подумаешь, выполнение произвольного кода при работе с юсб-устройством! Просто не пользуйтесь юсб, это все смузихлебство, lpt должно хватить всем! Но зато как быстро! И да, это все погромисты неправильные попались!
> Просто не пользуйтесь юсб, это все смузихлебство, lpt должно хватить всем!Ох еслиб, выпилили лптшки комерсы поганые
Эта хреновина (USB Gadget) в обычных потребительских дистрибутивах
не используеься, более того даже не присутствует в основных репах.
ну вот сколько анонимы опеннета им будут повторять, что дырявая сишка их в могилу сведёт, столько они будут в могилу сводиться
так они и жили. дырявая сишка сводила всех в могилу, а потом уставшие, но довольные возвращались домой и пили чай с пряниками.
Ох а сколько уязвимостей ещё не обнаружили...
Еще один бек-дор для СС (с служб) открыли. И их еще много остается!
ну да, ядро обновил со 190м бинарных вставок и вытер шок с лица
Webusb из хрома передаёт привет или он не подвержен?
>В дистрибутивах проблема пока остаётся неисправленнойНу, как обычно...