Разработчики мобильной операционной системы "Аврора" (локализованный вариант ОС Sailfish, развиваемый компанией "Открытая мобильная платформа") поделились показательной историей об устранении критической уязвимости (CVE-2020-6096) в Glibc, проявляющейся только на платформе ARMv7. Сведения об уязвимости были раскрыты ещё в мае, но до последних дней исправления не были доступны, несмотря на то, что уязвимости присвоен высокий уровень опасности и доступен рабочий прототип эксплоита, позволяющий организовать выполнение кода при обработке в функциях memcpy() и memmove() определённым образом оформленных данных. Исправления пакетов для Debian и Ubuntu не выпущены до сих пор и уязвимость остаётся неисправленной почти два месяцев с момента публичного раскрытия и пять месяцев с момента уведомления разработчиков Glibc...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53371
>компанией "Открытая мобильная платформа") поделились показательной историейдальше не стал читать...
> дальше не стал читать...А зря. Там слёзная история как их все игнорят.
Эх, не успел ответить, но кто-то уже поторопился написать в каменты про очередное сишное отверстие, хотя весь текст новости про голый ассемблер. В этом весь опеннет.Кстати,че там с memcpy на чистом, божественном русте?
Фрактал, он такой. Видит букву С - начинает издавать звуки курятника. Никак не научатся некоторые простой истине: язык - это инструмент. Ни больше, ни меньше. А то, что он даже не понял, а чём суть проблемы, достаточно характерно для "агрессивно-прогрессивных" комментаторов.
Потому что черты не знают, что по-русски этот язык называют и пишут Си, а не просто буквой "С", то есть "Эс", и уж тем более не "Цэ".
По-русски си и даже ц полее корректно, чем с. Ты совершенно безграмотный.
> полее...
> безграмотный.FAIL!
Сейчас бы ещё к опечаткам придираться. Они не имеют никакого отношения к грамотности. К тому же, чтобы замечать безграмотность, вовсе не обязательно самому быть грамотным. И моя (без)грамотность в любом случае за рамками данного обсуждения.
> Сейчас бы ещё к опечаткам придираться.В сообщении про грамотность? По-моему самое то :)
> Они не имеют никакого отношения к грамотности. К тому же, чтобы замечать безграмотность,
> вовсе не обязательно самому быть грамотным. И моя (без)грамотность в любом случае за
> рамками данного обсуждения.Размечтался, плюшевый.
> язык - это инструменту тебя точно язык - инструмент
Есть такая профессия.
> характерно для "агрессивно-прогрессивных" комментаторовдля агрессивный ретроградов актуально не менее (а именно на опеннет, чуть ли не более)
> сишное
> ассемблерВы либо крестик снимите, либо трусы наденьте. В your_favorite_lang тоже есть подобные уязвимости, но ввиду того, что сообществе считает your_favorite_lang неуязвимым, их никто не ищет.
Болгарки уже давно все на свалках - пилки для ногтей рулят!
Действительно, ведь высокоуровневые языки легко и просто получаются сами из себя, безо всяких там машинных кодов и режимов адресации. А вирусы — это когда HTML-письма с вредоносным JavaScript, а не самомодифицирующийся код.
да-да, давайте писать драйверы на electron.
> да-да, давайте писать драйверы на electron.Судя по https://github.com/offensive-security/exploitdb это не очень сильно помогает...
Ну что сказать, если по-твоему ассемблер - тупая поделка? Asm это почти 1:1 машинные инструкции. Ну давай выкинем на свалку истории машинные инструкции. Внезапно, а процессоры-то без них и не могут. Вот незадача-то...
Очевидно это был проосто жирный троллинг.
ОС Аврора такая же красивая, как её название?
>>пять месяцев с момента уведомления разработчиков Glibc.Не ожидал такого от GNU :( Всё время считал их более-менее ответственными ребятами.
Расслабилось сообщество, привыкли что шапка всё делает.
просто нужно время что бы забрать себе права на код. Тут не до каких-то багфиксов.
они озабочены только юридической проблемой - как забрать себе права на проект и что бы не дай бог принимаемый патч не нарушил их монополию на код.
(см ссылку из кода - https://sourceware.org/pipermail/libc-alpha/2020-June/114738...)А ты о каких-то технических проблемах.
С тебе деньги требуют? Они не парковщики подмосковья...
Эту либу используют миллиарды людей. Таки в их интересах, чтобы комар носа не подточил.
> Эту либу используют миллиарды людей.поэтому миллиарды посидят пол-годика с RCE, а мы пока подождем прав на код, тем более что нам самим наш работодатель redhatbm велел забить на эти arm32, и мы знаем, кто и за что нам платит.
Конечно, конечно, это такая забота о миллиардах.
А то ж какой-нибудь хуавей (извините за мат) может грязно над ними надругаться, предъявив свои права на код (заметим, под gpl - то есть эти права никак нельзя использовать во вред пользователям)
А что ты предлагаешь? Поставить миллиард людей на бабки? Это конечно мечта таких как ты но нет, обойдёшься. Если хочешь что бы быстрее было — то пинай авторов кода, это их первый опыт.
Linux kernel живет вон сколько лет без передачи всех прав на код, а эти все хотят подмять под себя.А так - пока что только GNU/FSF замечены в гнусных наездах и подставив для миллиардов людей на бабки. Когда перелицензировани gcc на GPL v3, и "случайно" забыли исключения. Это они лохам могут втирать о случайности, когда у них столько юристов на окладах.
Это только FSF/GNU может требовать у людей перелицензировать их код с GPL v2 на v3, когда код изначально брался под v2.
Это только FSF/GNU может выпустить новую версию лицензии которая не совместима со старой и этим самым подставить кучу проектов запретив им связывание со проектом под старыми лицензиями..Список подстав продолжать?.. или и так понять что FSF/GNU далеко не белые овечки.
Более того, с учетом недобровольной отставки Столлмана, совершенно неясно что они предложат в GPLv4, может придется на колени становиться перед мирными BLM протестующими для использования программы.
учитывая что всем мозги промыты что надо писать GPL vX or later. Все можно сделать одним движением пера ;-)
>поэтому миллиарды посидят пол-годика с RCE, а мы пока подождем прав на код, тем более что нам самим нашмиллиарды могут начать сами писать код. это опенсорс тебе никто ничем не обязан. это опенсорс возми сам и напиши.
где вы такие беретесь? ты читал новость внимательно?
люди написали код, написали патч - и еще 3 месяца трахались с утрясаем юридических формальностей связанных с передачей прав в GNU.
Копирасты хуже масочников.
Да не, как все.
Может у них просто нет железа, на котором девелопить можно, на ARMv7 или вообще на ARM.
Это железо стоит аж целых $50. Которых у них, ну конечно же, тоже нет - еле-еле на дошик хватает тех денег, что платит заботливая rbm.
(И "девелопить" на нем ничего не нужно, внезапно, для писания кода под арм не нужно это делать непосредственно на arm, ты бы еще код для суперкомпьютера писал прямо на нем, по $1000/час машинного времени. Железо нужно исключительно для тестирования уже написанного - и даже, возможно, уже скомпилированного - хотя вряд ли последнее, ведь разработчики инклюзивно-альтернативной ориентации не умеют кросскомпиляцию, но у них есть девоп который за них настроит всю ci музыку. Только ему тоже rbm зарплату платит. А у нее нет версии для arm32, и девоп не может ничего настроить - ведь он умеет только rhel.)
> Это железо стоит аж целых $50.То, на котором можно как-то проверить -- дешовле даже.
То, на котором можно нормально гонять регрессионные тесты -- см. ценник на машинки на Hi1616, например.Ну и помимо наличия железки надо ещё и знать её ассемблер _плюс_ glibc.
Huawei Technologies Co., Ltd Hi1616 Processor 2.4 GHz: RAM: 64 GB: Ports and Bus Types: 8 PCI Express X8: Video Adapter: Huawei Technologies Co., Ltd Hi1710: Host Bus Adapter: Huawei Technologies Co., Ltd Hi1616 Integrated SAS Controller , Serial SCSI (SAS) Hard Disk Drive:это вот все шибко необходимо для регрессионных тестов? Банальный odroid или старая rpi никак не справятся? Может, в консерватории чего поправить, или пора может уже писать тесты для писателей тестов - если их тест не может работать на +/- той же платформе, для которой предназначен код (а canbus контроллеры ни разу не хайэнд железо) - нахрен он нужен, и нахрен нужен такой тестописатель, который не в состоянии это сообразить?
> Ну и помимо наличия железки надо ещё и знать её ассемблер _плюс_ glibc.
дааа, с этим у современных разработчиков, конечно, сложности - они только markdown знают... в принципе, для "кода" лицензии ничего больше и не надо. Остальное должен делать хуавей, вот, например!
И подавать с поклоном, ниже, ниже, сволочь узкоглазая кланяйся господину! А то не возьмем!
Кретин, там же не один тест запускают, а всю пачку ранее написанных тестов на регрессии. Они запускаются дольше чем сборка самой glibc происходит
> Кретин, там же не один тест запускают, а всю пачку ранее написанных
> тестов на регрессии. Они запускаются дольше чем сборка самой glibc происходитСлышь, гений, а чего мешает разбить пачку на несколько мелких и дешевых одноплатников? Да и вообще, машины как таковые не особо то и торопятся, времени у них много. А через сколько там именно бэджик статуса вывесится - а оно вот прям так срочно и вы сами лично ждать это чтоли будете? В общем не понимаю я этой гигантомании, когда без 10 гиг зернета видите ли жизни нет.
> Слышь, гений, а чего мешает разбить пачку на несколько мелких и дешевых одноплатников?или просто подождать пока единственный выполнит их последовательно (коли денег на дошик таки не хватает - ты, наверное, не захочешь платить за пачку)
Машина - она железная.Но вы только что видели типового современного разработчика - ему ждать некогда, смузи скиснет. Если для тестирования не предоставлен суперкомпьютер - мы не будем исправлять rce, наш смузи и без того прекрасен.
А вот донейтов, кстати, надо бы поклянчить - а то за редхатовскую зарплату-то еще ж и работать заставят, тамошним менеджерам не скажешь "это опенососе, вам тут никто ничем не обязан, вам надо - вы и пишите!" - сразу от краника-то подвинут.
Казалось бы, элементарнийшая функция, а до сих пор пишут на асме для производительности. ужас!
А на чём надо? На пайтоне?
смищно про питон, а че, С не смог соптимизировать цикл?
Ничего смешного. Критичные куски кода всегда писались на асме.
Как я понимаю, вы сами про оптимизацию ассемблерного кода только слышали. И актуальность выжимания максимума скорости из memcpy/memmove слабо представляете.
>вы сами про оптимизацию ассемблерного кода только слышали.ну давай, срывай покровы. Какие такие супер оптимизации нужны в memcpy и почему их до сих пор не научился делать Сишный компилер ?
Очередной адепт секты всемогущего компилятора ?В случае x86 это хотя бы использование инструкций rep movs[bwlq].
>В случае x86 это хотя бы использование инструкций rep movs[bwlq]Он умеет это делать.
Они не всегда нужны.
СТ.
Интринсики. (ПАРКУР ЕЕЕ)
И сложно говорить про низкоуровневые оптимизации в циске.
Не умеет, ни gcc, ни clang rep movs не генеруруют.
Нужны, особенно в функциях типа memcpy/memmov/memset.
Интринсики не спасают от говнокода, который сплошь и рядом генерирует компилятор.
> Не умеет, ни gcc, ни clang rep movs не генеруруют.
> Нужны, особенно в функциях типа memcpy/memmov/memset.
> Интринсики не спасают от говнокода, который сплошь и рядом генерирует компилятор.а почему не умеют? вроде ж просто определить необходимость и вставить?
> Не умеет, ни gcc, ни clang rep movs не генеруруют.Doubt Press X
>-mstringop-strategy
> Нужны, особенно в функциях типа memcpy/memmov/memset.Если надо скопировать 1 байт - нет.
И еще много интересных случаев, когда не надо.> Интринсики не спасают от говнокода, который сплошь и рядом генерирует компилятор.
Еще как, их придумали, чтобы компилятор не страдал фигней, как сейчас в расте.
Чтоб скопировать 1 байт (int,long) вообще вызывать memcpy?
ты погоди. Сейчас у этого смузихлеба вообще крышу снесет:ТЫ ПРИКИНЬ ДАЖЕ В ТВОЕМ ЛЮБИМОМ GO КУЧА АССЕМБЛЕРНЫХ ВСТАВОК.
> ТЫ ПРИКИНЬ ДАЖЕ В ТВОЕМ ЛЮБИМОМ GO КУЧА АССЕМБЛЕРНЫХ ВСТАВОК.Просто у них там деление на богов, которым так можно, и червяков, которым так низя. А у сишников считается не зазорным и вот так, если оно вдруг здорово все улучшает. Главное чтобы такого немного и/или с чисто севыми фаллбаками было, иначе на другую платформу портировать замумукаешься. Собственно самая большая граблина ассемблера - в том что при нужде перейти на другую архитектуру вы переписываете всю программу с нуля.
>ТЫ ПРИКИНЬ ДАЖЕ В ТВОЕМ ЛЮБИМОМ GOТак и запишем. Сишное говно ни на что не годно. Можно спокойно писать на расте, всеравно критические части прийдется писать на ассемблере.
> Так и запишем. Сишное говно ни на что не годно.Ну, ты хотя-бы сишный кернел операционки уже выкинул? :)
>Ну, ты хотя-бы сишный кернел операционки уже выкинул? :)Ага "Сишный". Ша копну поглубже, и окажется что все критические части на асме писаны.
А сишники только и могут что хвастаться какой у них язичЁк простой и быстрый.
Все такие умные тут, Думают что в C нельзя запихнуть GC или другой метод управления памятью, и всякие другие причиндалы модно-молодежных языков. Слышать о языке и написать hello world, и использовать его - это разные вещи. Пока нет языка высокого уровня , который бы мог соперничать с C в его простоте, мощности и быстроте. Все его конкуренты страдают от одной и тоже болезни: а давайте в язык эту фичу запихнем. Кстати последнии несколько стандартов Си тоже страдают этой болезнью.
> ДАЖЕ В ТВОЕМ ЛЮБИМОМ GO КУЧА АССЕМБЛЕРНЫХ ВСТАВОКВы все врёти!!!11рас
Потому что компилятор не в курсе где и как будет использоваться функция? Он тебе соптимизирует для общего случая или для конкретного приложения, для системной библиотеки которую используют из всех языков программирования это не всегда верно.
>Он тебе соптимизирует для общего случаяЧто за чушь! компилятор оптимизирует так как ему сказали через опции командной строки.
Бывает ещё runtime информация, которой кичатся все любители JIT. Её никакими опциями не укажешь.
>Бывает ещё runtime информация, которой кичатся все любители JITКаким боком твои откровения к обсуждаемой теме ? Типа умный ?
Тем, что опции просто говорят как хорошо нужно оптимизировать файл для общего случая. Частный, ты никакими опциями не настроишь, так как дело вовсе не в конкретных машинных инструкциях. А вот ассемблерными вставками вполне возможно оптимизировать то, на, что компилятор решится не может так как рискует наоборот ухудшить производительность, если не угадает замысел программиста.
И-и-и-, тот memcpy в новости на асме для конкретного случая, или для всех на свете, где glibc будет использоваться?
Для случаев которые происходят гораздо чаще других. В редких он вполне может медленнее варианта на Си. В том и разница, что компилятор не способен оценить вероятность использования не проанализировав возможность взаимодействия каждой строчки программы с каждой. Пример: код printf("%s\n", "Hello, World!"); развернётся в множество больших функций, а на Ассемблере это всего 4 машинные инструкции. Когда компилятор может проанализировать вероятности, то его код безусловно будет лучше полуобщего ассемблерного варианта.
Потому что разные компиляторы с разными ключами сборки генерируют разный код? Как ты собрался гарантировать повторяемость кода и поведения на всех платформах и всех компиляторах?
>компиляторы с разными ключами сборки генерируют разный код?C твоих слов, так компилятор для разных платформ можеть нагенерировать разного неповторяемого непонятно чего.
И тогда скажи, а зачем мне такой компилятор, если ему даже лабу нельзя доверить компилять. Потому что в общаге результат норм, а в универе - уже не то ?
Потому что если он что-то неэффективно скомпилирует в коде отрисовки кнопочек на форме, это совсем не то же, как если он скомпилирует неэффективную реализацию memcpy — функции, которую могут вызывать для разных областей памяти разного (на пяток порядков) размера тысячи раз в секунду.Зачем спорить? Скомпилируйте свою версию memcpy и посмотрите на неё дизассемблером, да тесты прогоните.
И, да, rep movsb на x86 — это НЕ эффективно.
>Потому что если он что-то неэффективно скомпилируетТак в этом и вопрос, Если компилятор годиться только формочки клепать - то НАФИГ такой компилятор.
Вы ещё и в компиляторах, значит, не разбираетесь... Идите, покажите, как надо. Тысячи разработчиков компиляторов по всему миру ведь явно такие тупые, что за более чем полвека не смогли «нормальный» компилятор сделать, который бы все чаяния программиста угадывал.Вам Ordu уже детально расписал конкретно по memcpy, сколько там нюансов. И это лишь одна из множества типовых операций, выполняемых программами.
Может быть, вы не в курсе, но при разработке компилятора скорость конечного кода имеет не наивысший приоритет. Куда важнее корректность и полнота реализации языка. А сами по себе языки программирования служат задаче уменьшения времени и сложности разработки. Вы же как пользователь предпочтёте работающую, пусть и не идеально быстро, программу сейчас, чем идеальную примерно никогда? Вот и придумывают порой жутко неэффективные (по сравнению с чем-то там), но работающие здесь и сейчас инструменты.
>Вы ещё и в компиляторах, значит, не разбираетесь...ты то дохрена разбираешся, ни одного толкового ответа, все какието съезды про то как все трудно.
>Идите, покажите, как надо.
5 минут поиска выдали вот такой проект - https://github.com/skywind3000/FastMemcpy/blob/master/FastMe...
вот ведь, оказывается можно писать на С.
> ты то дохрена разбираешся, ни одного толкового ответаТолковые ответы вы уже не раз получили. Раз не смогли нормально отреагировать, то теперь получайте вариант для чайников и не жалуйтесь.
А разбираюсь достаточно, чтобы писать и отлаживать код и на ассемблерах, и на Си, и на высокоуровневых языках. Вот только это не я тут заявляю, что Си — дурацкий язык с дурацкими компиляторами, которые ВНЕЗАПНО не умеют генерировать идеальный код.
> вот ведь, оказывается можно писать на С.
Ну да, обернули каждую команду SSE в сишную функцию, а потом делаем вид, что программируем на Си, и, вдобавок, продолжаем полагаться на эффективность компилятора.
Ещё раз говорю: возьмите чисто сишную реализацию memcpy (можно этот код), скомпилируйте, отправьте результат в дизассемблер (вы же objdump пользоваться умеете, правда?) и сравните с «ручной» реализацией хоть из того же glibc. А потом производительность сравните. Вопросы отпадут.
Если же не можете сделать даже это, то перестаньте придуриваться и начните внимать чужим объяснениям. Потому что если своего ума не хватает, придётся жить чужим, увы вам.
> компилятор для разных платформ можеть нагенерировать разного неповторяемого непонятно чегоДа. И это хорошо известно всем, хоть раз писавшим код под МК.
> смищно про питон, а че, С не смог соптимизировать цикл?Как-то смог, но на асме оказалось вот быстрее. Прикинь, в чувствительных к скорости местах до сих пор полно асма.
для сегодняшнего поколения тормозов java vm внутри java vm внутри java vm без JIT это норм скорость. чем тормозней тем больше смузи можно выпить. Ну и в офисе и дома тепло от кипящего процессора, удобно жу, можно обогреватель не включать
> удобно жу, можно обогреватель не включатьГлавное не забыть зарядить свою жаба-тормозилку с электронами вечером, иначе утром она в тыкву превратится.
А такие вещи как memcpy/memmove очень сложно написать на высокоуровневом языке так, чтобы компилятор смог бы сгенерить код, который выжмет максимум пропускной способности. Но дело ведь не только в пропускной способности, но и в latency: memcpy/memmove может вызываться много-много раз на мелких кусках памяти, и если каждый раз они будут тупить, выбирая наилучшую стратегию копирования, то всё равно получится плохо.То есть, это выглядит примерно так:
int memcpy(void* src, void *dst, size_t size) {
const size_t block_size = 8;
const size_t unroll_count = 4;
size_t count = size / (block_size * unroll_count); // тут лучше shift'ами естественно, но можно надеятся компиль справится.
size_t rem = (size / block_size) % unroll_count;
size_t n = 0;
switch(rem) {
case 0: goto first; // я не совсем уверен, что любой компилятор C на любой платформе позволяет входить в цикл таким образом.
case 1: goto fourth;
case 2: goto third;
case 3: goto second;
}
for(; n < count; n ++) {
first:
*(uint64_t*)dst = *(uint64_t*)src;
src += block_size; // кстати, я не помню что там стандарт C говорит об арифметике на void*, может стоит преобразовать к char*, хотя gcc вроде умеет, делая вид, что размер void -- 1 байт.
dst += block_size;
second:
*(uint64_t*)dst = *(uint64_t*)src;
src += block_size;
dst += block_size;
third:
*(uint64_t*)dst = *(uint64_t*)src;
src += block_size;
dst += block_size;
fourth:
*(uint64_t*)dst = *(uint64_t*)src;
src += block_size;
dst += block_size;
}
// ах да, надо ещё для return'а сосчитать сколько скопировано...
}Ну так вот, и это базовая имплементация. Тут ещё надо обработать случаи, когда size < block_size. Реальная имплементация, при этом, может, например, использовать регистры SSE или AVX для того, чтобы копировать (потому что они большие), то есть тебе придётся компиляторные builtin'ы подключать. С memmove ещё забавнее, потому как в зависимости от того, что и куда копируется, надо иногда копировать от начала к концу, иногда от конца к началу, а иногда лучше вызвать fallback'ом memcpy.
Ах и да, эта имплементация не везде сработает: она точно будет работать, если src и dst выровнены на границу кратную 8 байтам, но на некоторых платформах она может начать тормозить, если они не выровнены, или даже вообще откажется работать. Если использовать всякие там SSE и AVX, то точно начнёт тупить или не работать, в зависимости от того какие builtin'ы ты использовал. То есть надо ещё проверить выровненность и в зависимости от того, что там с ней, либо выровнять адреса, скопировав пару байт каким-нибудь тупым образом, либо копировать с невыровненного в выровненный или с выровненного в невыровненный. Короче, писать такое на C -- себе дороже. Проще написать на ассемблере. А поскольку memcpy используется во все поля, то и забить на его оптимизацию -- не вариант.
Но я всё это к тому, что если ты напишешь что-то в стиле:
char *dst = (char*)dst;
char *src = (char*)src;
for(i = 0; i < size; i ++)
(*dst++) = (*src++);то компилятор C совершенно точно не будет тебе генерить простыни машинного кода наилучшей реализации memcpy под данную платформу.
Интересно, общались ли с изначальным разработчиком memcpy под armv, неким Nicolas Pitre?Или ему уже по барабану на код, написанный 14 лет назад: https://github.com/bminor/glibc/commit/0572b91bdb6cf4dda3bb2...
> Интересно, общались ли с изначальным разработчиком memcpy под armv, неким Nicolas Pitre?И какой вопрос следовало бы ему задать, на твой взгляд?
На кого он работает. Кто приказал добавить эксплойт в глибс. Какое звание ему присвоили после удачной операции.
Завидовать дурно!
А идея что Nicolas тогда был просто студентом или начинающим разработчиком и просто ошибся тебе конечно в голову не приходит.
Был - студентом. Стал - сразу капитаном, внеочередное дали за боевые заслуги. Уже на пенсии, между прочим, неплохой.
(майором - никогда не будет, у майора свои дети есть)
Когда есть критическая уязвимость, всем должно быть нaсрать на производительность. Тем более в выделении памяти на куче, которое и так медленное, ибо обычно требует сисколлов.Вместо тактодрочерства нужно БЫСТРО выкатить хоть-какой нибудь патч, закрывающий уязвимость, и только потом уже вылизывать скорость.
компании SUSE и Red Hat объявили, что их платформы проблеме не подвержены ...
Быстро выкатить пачт на андроид? Смешно.
На большинство телефонов его вообще не выкатят.
где glibc и где Андроид ?
У них там свой бионик.
> БЫСТРО выкатить хоть-какой нибудь патч, закрывающий уязвимость, и только потом уже вылизывать скорость.Как бы оно да... Но в нынешнем мире часто "а потом" не наступает никогда. Правда, это в коммерческой разработке.
> Когда есть критическая уязвимость, всем должно быть нaсрать на производительность.Вы видимо тут новенький и первый раз столкнулись с критической ошибкой. Не всё так просто, иногда существенная деградация производительности может создать другую уязвимость, например DoS.
DoS по ресурсам невозможно создать, его можно только отсрочить или приблизить.
тысячегласс, kokokoko!А мэйнтейнеры glibc очень заняты - "разрабатывают наборы тестов", им некогда исправлять rce в glibc.
Тесты — это хорошо и правильно. Вот только для таких критичных компонентов они должны быть готовы заранее...
Великая победа Альянса!
Кек
Доигрались со своими нанооптимизациями. Казалось бы, что проще - байтики скопировать?Помните же, как сломался звук во Флеше? Тогда наивная Линусовская реализация memmove оказалась по тестам ничуть не менее производительной, чем все эти пляски с бубном с копированиями в разные стороны и прочими middle out (tm).
Задним умом у нас все крепкие.
> Казалось бы, что проще - байтики скопировать?Казалось бы, что проще — комментарий на форуме оставить? А расскажите-ка в деталях этот процесс. Хотя бы до L3 модели OSI, не будем уж совсем зверствовать.
>Хотя бы до L3 модели OSIОхренеть, а когда это в memcpy добавили поддержку сети? или абы ляпнуть ?
>> комментарий на форуме оставить?
>> Хотя бы до L3 модели OSI
> или абы ляпнуть?А ещё перлятников обвиняют во write-only...
Забавный момент: неокрепшие студенческие умы, не закостеневшие от использования Java или там PHP, куда охотнее берутся за Perl. А write-only я больше всего видел на Bourne shell пока что. :)
Я лишь попробовал, раз уж специфику memcpy здесь явно понимает менее 5% посетителей (не в укор), то, может хотя бы действие, которое местные комментаторы и так по определению производят, смогут описать. Ну там: браузер формирует HTTP-запрос, кодируя в нём таким-то образом такие-то данные, полученная простыня отправляется в write(2) или аналогичный API... Это, вроде бы, должно быть лучше знакомо, чем особенности ассемблеров и компиляторов Си на разных платформах.
Скопировать в адресное пространство контроллера.
Сказать отправить.
Ждать готовности.
?
А можно прочитать где-нибудь о контроллере, умеющем отправлять комментарии на OpenNet? Очень интересно глянуть.
> Тогда наивная Линусовская реализация memmove оказалась по тестам ничуть не менее производительнойЭто во первых не так. Во вторых никакой ошибки в memmove тогда не было, ошибка была у adobe так как они не прочитали документацию и нарушили API про которое было явно написано что так делать нельзя.
Кто вам платит за распространение мусора в русскоязычном интернете?
Вот вам развёрнутое чтение на этот счёт. https://avva.livejournal.com/2323823.html В дополнение к нему, опишу своё видение проблемы. Хоть и не являюсь программистом, но прочитал разные мнения в разных источниках. Итак, есть memcpy(), низкоуровневый вызов, который нужно выполнять _быстро_. Если выполнить поиск по коммитам в GIT-репозитории Glibc, можно увидеть, как вызов улучшали SIMD-инструкциями, начиная ещё с MMX. Компания Intel отправила патч, добавляющий оптимизацию и для SSE4 тоже. Но оптимизация оказалась не эффективной при традиционном порядке байт, поэтому патч пробует и обратный порядок тоже, чтобы достичь ускорение.При этом вызовом memcpy() всегда и на всех платформах пользовались только в традиционном порядке байт. Стандарт молчит о порядке байт, поэтому все поступали так потому, что такова традиция. Патч, добавляющий оптимизацию SSE4, был первым разом, когда порядок байт развернули. Когда пользователи начали жаловаться, Дреппер сказал "если стандарт молчит, значит порядок может быть любым". Он настаивал на том, что проблема проявляется только во флеше, и нигде больше - а флеш проприетарен, значит дефективен, а значит так им и надо. Ему и проблемы из других проектов приводили в пример, и цитаты из фундаментальных книг по программированию - но Дреппер всё равно вёл себя, как asshole.
P.S. В openSUSE в то время проблему решили патчем glibc-disable-backward-memcpy.diff, потом ситуацию всё же разрулили в апстриме, и патч убрали. Странно что в апстриме рассматривали разные способы решить проблему - вплоть до алиаса memcpy() вокруг memmove() - но никак не "вернуть всё как было". А разве можно допустить, чтобы оптимизация на SSE4 не показала прирост в бенчмарках? Что же тогда, пользоваться SSE3, который уже не модный?
юридическое оформление патча? в memcpy? мде...
В glibc.
> Месяц заняло тестирование и юридическое оформлениеМда, и как тут Адама Дугласа не вспомнить с его Вогонами.
> Адама ДугласаТипа сумничал?
Т9 исправил где не просили
Как не знать Адама Дугласа! Он же ещё написал "Ноты Гуге".
Вогон, залогиньтесь!
Вогон, выйди вон!
Ну конечно все древние Андройд разработчики побегут обновлять свои древние АРМ7 телефоны.
Откуда в android взялся glibc? Комментаторы на опеннете такие комментаторы.
> АдройдМожно было вообще не смотреть этот коммент дальше, и так всё понятно.
В ведроиде в блобах уязвимости, которые вообще невозможно легально пофиксить. Проприетарь, не хочешь такое юзать - сиди совсем без телефона.
>сиди совсем без телефонаКупи кнопкофон "военный".
> Купи кнопкофон "военный".РацЫю, кули. Старую. Заодно и поднакачаешься слегонца.
> Проприетарь, не хочешь такое юзать - сиди совсем без телефона.Не хочу. Сижу с S40 и SFOS. Правда, тоже проприетарь.
«Не хочу юзать проприетарь, поэтому юзаю проприетарь.»Весёлый ты.
>>>> В ведроиде...
>>> Проприетарь, не хочешь такое юзать - сиди совсем без телефона.
>> Не хочу. Сижу с S40 и SFOS. Правда, тоже проприетарь.
> Весёлый ты._Такое_ -- нет, не хочу, ха-ха-ха.
> «Не хочу юзать проприетарь, поэтому юзаю проприетарь.»Это Шигорин, у него всегда с логикой - "не очень".
Фактически патч от Авроры повторяет от Хуявея, только интсрукции заменены дополнительно в 3ех местах.
Фактически патч мог написать и оттестировать любой байтолюбитель за неделю. Странно, что всем по факту было до лампочки столько месяцев.
Ничего странного, ARM7 32 бит это в основном проприетарные поделки, их авторам проблемы их пользователей до лампочки по определению.
> Ничего странного, ARM7 32 бит это в основном проприетарные поделки, их авторам
> проблемы их пользователей до лампочки по определению.А пардон, чего не проприетарные? Интель с management engine и блобами в FSP ажно? :)
Да! Это же патч как от Хуавея, только другой!
не только. Там подозрительно выброшены два куска, не очень понятно, безобидное ли это изменение - я тоже не разбираюсь в ассемблере arm (и в glibc), но выглядит подозрительно - раньше регистр модифицировали, и что-то дальше с ним делали, теперь просто сравнивают. Что это вообще было-то?
Фу, сколько пиара нашынской поделки.
Ну хоть кто-то сделал. Вот то, что вообще используется 32 бита, это, конечно, печально, но гну мог бы быть и порасторопней. Лг6т шайка прогнала Столлмана и пошла в разнос?
Ох, не занимались бы овнокодеры, не видящие разницы между беззнаковыми и знаковыми сравнениями на асме, запиливанием целой *libc.
Они, походу, видели - и нарочно сделали знаковое. Фиг знает, зачем.вот это вот:
- bge 3b
- PLD( cmn r2, #96 )
- PLD( bge 4b )
- что вообще было такое, и почему это можно оказалось выбросить? [в новом коде нет перехода по второй ветке никогда]
Вы знаете у меня то же иногда возникают подозрения. Сами закладывают, и потом сами же выкатывают устранения уязвимостей. Однажды прогнал через шланг btusb.c (драйвер из ядра линукс) - нашёл два места обращений явно за пределы массива, и это в статике! И заметте, многие PR висят годами и никто не чешится их применять, хотя очевидно исправляют какую либо проблему.
> Сложность заключалась в том, что нужно было написать эффективную ассемблерную реализацию функции и учесть при этом различные варианты входных аргументовнет.
сложность очевидно была в том что никому нафиг не упали железка с aarch32 , в то время как уже 2020 год и все перешли на aarch64 ..
не удивительно же что было тяжело исправлять
Угу - это раньше "шестисотый" братва выкидывала потому что пепельница опять переполнилась. Теперь ты свою китайскую помойку выкинешь потому что в ней немодный процессор в can, и сосед со своей мобилы перехватив управление, отправил ее в столб.
(Впрочем, китаец о тебе уже позаботился, и она просто не открывает тебе двери, чтобы ты не мог ездить на такой небезопастной. Ну и кого колебет что ты оказался внутри а не снаружи? Зато безопастно!)Глядя на армовский кластер под столом - ну и да, конечно же, "потому как уже 2020й год" мне его надо выкинуть и купить новый-модный, на aarch64 (сколько лет вообще эта архитектура существует - три годика, да?) - и так каждый год, ну максимум - раз в два.
То чувство, когда о какой-то ОС Аврора узнал из новости о том, что её разрабы залатали дыру в Glibc
> То чувство, когда о какой-то ОС Аврора узнал из новости о том,
> что её разрабы залатали дыру в GlibcНу, хоть какая-то польза от этих господ наконец.
>> То чувство, когда о какой-то ОС Аврора узнал из новости о том,
>> что её разрабы залатали дыру в Glibc
> Ну, хоть какая-то польза от этих господ наконец.Польза от них и раньше была, если что.
Вам на блюдечке с голубыми декорациями они её доносить не обязаны.
Как и Вы -- скажем, мне.
> Польза от них и раньше была, если что.Это когда они наврали с три короба про открытие исходников и потом вообще ростелекому слились?
> Вам на блюдечке с голубыми декорациями они её доносить не обязаны.
> Как и Вы -- скажем, мне.Абсолютно, но я им тоже позитивное мнение о их деятельности не обязан, например.
потому что гну - всё...
GNU не одно и тоже, что FSF. Хоть и были связаны через RMS'а.
Ну теперь заживем!
Русские программисты: *постоянно контрибьютят в опенсорс, работают во всех мировых айти-компаниях, занимающихся СПО*
Разработчики OC Аврора: мы пропатчили Glibc и напишем об этом статью на опеннете
> Русские программисты:
> Разработчики OC Аврора:Забавное противопоставление. Сами-то чьих будете, куда патчей насовали?
Чего забавного? Первые гребут на галерах, во всяких пейсбуках и прочих помойк...мировых иты-компаниях, куда только они да индусы и нанимаются, мечтают подсидеть индусского тимлида и сами стать такими (на большее мечт не хватает, да и некогда, тимлид кнутом больно лупит).Другие, сволочи, в рабочее время патчат glibc, да еще нагло пиарятся на опеннете (неиначе - мест в пейсбуке жаждут, набивают себе цену) - а у тех, первых - nda, а при попытке договориться - индус вкрадчиво спрашивает "а тебе что, делать нечего?" - ласково поигрывая при этом кнутом.
> проявляющейся только на платформе ARMv7Какая избирательность. Напомните, Android на glibc работает?
Какже достали все эти интовые наследия!
int main(...int argc) // ok, ребята, нам прислали -5 аргументов, держитесь!