В развиваемой альянсом Open Media (AOMedia) библиотеке libaom, предоставляющей эталонную реализацию формата кодирования видео AV1, выявлена критическая уязвимость (CVE-2024-5171), приводящая к целочисленному переполнению и записи в область вне границ буфера при обработке слишком больших значений в некоторых параметрах. Аналогичная уязвимость (CVE-2024-5197) выявлена в библиотеке libvpx с реализацией кодеков VP8 и VP9. Проблемы устранены в обновлениях libaom 3.9.0 и libvpx 1.14.1. В дистрибутивах уязвимости пока остаются неисправленными (Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, FreeBSD)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61323
SVT-AV1 FTW
Причем скорость кодирования в последних билдах практически сравнялась с x265, так что патентный хлам можно закапывать - качество на голову выше.
На системах с двумя видеокартами?
>На системах с
Эта дрянь ужасно выглядит, подходит только для звонков. Nvenc получше (особенно h265 в Ada Lovelace).
> Nvenc получше (особенно h265 в Ada Lovelace).Позволю себе процитировать вас - "Эта дрянь ужасно выглядит". Простите, но 265 это вообще мертворожденный кодек по сути. Истеричные дергания исы с выпеканием кучи кодеков намекают что соотношение аппетитов патентных троллей к фичам битстрима - ни к черту вышло. Зачем оно вообще такое? У него на уровне потока нет эффективных coding tools для уменьшения битрейта, в отличие от халявного AV1. И за этот BS еще платить предлагается?! Патентное тролье совсем охренело, только вот перегнули палку - появился AOM - и теперь подобная деятельность обломается.
За всё уплочено. H265 не выглядит ужасно, 100% качественного контента именно в этом формате. И он занял абсолютно весь рынок (качественного контента) больше 10 лет назад. Альтернатив просто не существует -- и vp9 и av1 достаточно дефективные по целому ряду параметров. Что там на телефонах смотреть понятно разницы нет. Я лично не сравнивал аппаратные кодеры av1, но уверен, что они проиграют libaom в сравнении. И libaom уже проблемный кодек.
> За всё уплочено. H265 не выглядит ужасно,Если вы уплатили за кривой трэш - да это ваши проблемы.
> 100% качественного контента именно в этом формате.
Это заявление не соответствует действителньности: Netflix и Youtube используют AV1 для именно наиболее качественного контента.
> И он занял абсолютно весь рынок (качественного контента) больше 10 лет назад.
Широко известный в узких кругах... хехехе, туда и дорога фигне от патентных троллей.
> Альтернатив просто не существует -- и vp9 и av1 достаточно дефективные по целому
> ряду параметров. Что там на телефонах смотреть понятно разницы нет.H.265 едва-едва может зарубиться по битрейт-качество с древним VP9 - который халявен много лет, поддерживается кучей софта, играется даже доисторическим планшетом которому 10 лет, и это все здесь и сейчас, на миллионах роликов с ютуба.
А H.265 - ну, он где-то есть. Я не уверен что у меня в нем хоть 1 файл вообще существует. Так что он крутой и нужный. Где-то там. В фантазиях патентных троллей.
> Я лично не сравнивал аппаратные кодеры av1, но уверен,
"Пастернака не читал но осуждаю" (c).
> что они проиграют libaom в сравнении. И libaom уже проблемный кодек.
Для 265 и таких нет, то что есть - даже SVT1 по битрейт-качество с треском сливают в общем случае.
Где AI кодирование? Он по прежнему шакалит стоящего на переднем плане человека когда на заднем плане плещутся волны? Это так сложно вырезать маской человека и сказать кодеку чтобы битрейт преимущественно на то что находится в маске? Это жрет настолько мало ресурсов, что в 2024 с этим справляются дешевые встроенные процессоры в ip камерах видеонаблюдения, в реальном времени.
> Где AI кодирование? Он по прежнему шакалит стоящего на переднем плане человека
> когда на заднем плане плещутся волны?А титры в Big Buck Bunny 265 вообще просто в труху убивает на любом разумном битрейте. А на неразумном - нахрен нужно кодировать с эффективностью divx сжирая проц круче 264?!
А вот AV1 своим global motion compensation с таким подарком судьбы неплохо справляется и это неплохо выглядит даже на умеренном битрейте. Аналогично и с иными подобными случаями.
Закапывать вместе со старым железом, мобильниками и ноутбуками прежде всего?
Да. Граждане которые сидят на мусорном железе априори для бизнеса являются балластом, который не приносит денег.
Понял, не новые кодеки с уязвимостями мусорные, а старое железо)
Утверждение — полная глупость. Чем для условного адоба граждане с десятилетними ПК (селероны с XP оставим за бортом, ладно) являются вторым сортом? И на этих ПК условный фотошоп прекрасно работает, разве что не так резво.
> Закапывать вместе со старым железом, мобильниками и ноутбуками прежде всего?На совсем старом - xvid смотри, и прочий 360p с ютуба. А какие у тебя еще варианты есть? А все остальное и сабж в разумных пределах прожует.
Svt-av1 очень мыльный и раздувает битрейт где не надо, артефачит. Переходи на VVenC, отличный кодек, ощутимо превосходит libaom. И быстрее/эффективней на среднем/быстром пресете. И для начала, x265 это поделка от индусов без определённой функциональности формата H265, я знаю точно, что как минимум референсный кодер картинку ощутимо лучше выдавал.
Почитайте форумы что ли. Откройте для себя "--tune 0 --enable-qm 1 --qm-min 0 --qm-max 15".
> Почитайте форумы что ли. Откройте для себя "--tune 0 --enable-qm 1 --qm-min
> 0 --qm-max 15".Он поди еще и тестировал это на древней версии какой-нибудь. То что за пару лет открытый кодек может огрести дохреналион комитов - в том числе от спецов - заметно улучшающих такие аспекты - гражданин явно не в курсе.
На той неделе только провёл вполне основательное тестирование, чем там заменить x265 можно. И vvenc чуть дороже, но качество и битрейт значительно превосходят все альтернативы, libaom, кстати, частично забракован из-за неспособности фильровать уже существующие в потоке артефакты AVC, как это делают, к примеру, x265 и vvenc. Ну и артефакты с милом никуда не деваются, он даже на ровном месте накинет их. С "твиками" вся картинка разъезжается на артефакты. А вот svt-av1 ни в какие ворота Специально сравнивал на лучших пресетах, а потом на аналогичных по вычислительной сложности. Тот же x265 может насыпать волосатых краёв, но детализация деталей намного выше. Не было такого, что текстура выезжает за край.
> На той неделе только провёл вполне основательное тестирование, чем там заменить x265 можно.Я вообще не понимаю нахрен его использовать. По битрейт-качество формат ни о чем, уже де факто устарел, в вебе не играется. И достоинств у него - "заплачено патентным троллям" чтоли? Ну такое себе преимущество, сильно для некоторых.
> И vvenc чуть дороже, но качество и битрейт значительно превосходят
> все альтернативы,И, как обычно, сравнений и пруфскринов мы не увидим, как и воспроизводимых параметров теста?
> libaom, кстати, частично забракован из-за неспособности фильровать
> уже существующие в потоке артефакты AVC,Не вижу с этим никаких проблем при использовании ffmpeg, воткнуть ему какой-нить -vf pp, а то что это отдельный модуль - так даже лучше, модулей несколько, на разные оказии. Можно заодно какой-нибудь кривой interlace прибить - или шум в темноте урезать, нафиг кодировать цветные артефакты если вещи типа hqdn3d трехмерным усреднением их отлично сносят без ущерба контенту почти?
> как это делают, к примеру, x265 и vvenc.
Очень нишевой кейс не идущий в сравнение с тем что ffmpeg может предложить - с фига оно достинство хз.
> Ну и артефакты с милом никуда не деваются,
Вон там человек для тех кто в танке дал параметры. Вполне себе деваются, надо было просто doom9 немного почитать по теме чтоли. Хоть 5 минут, для summary.
> разъезжается на артефакты. А вот svt-av1 ни в какие ворота Специально
> сравнивал на лучших пресетах, а потом на аналогичных по вычислительной сложности.
> Тот же x265 может насыпать волосатых краёв, но детализация деталей намного
> выше. Не было такого, что текстура выезжает за край.При более менее агрессивных битрейтах с прицелом на интернет x265 вообще рядом с svt1 не стоял по битрейт-качество. И тут уж надо определиться о чем мы. Если про артефакты - наверное это не ультра хд контент был. А если уж про компактное кодирование и агрессивную оптимизацию битрейт-качесво - там x265 вообще нечего ловить. Вот реально единственный кейс - bdrip для варезников кодить. Для остального он нафиг не упал. Потому что отстоен.
> Svt-av1 очень мыльный и раздувает битрейт где не надо, артефачит.Вы его в какой версии видели? Букмарки надо иногда апдейтить. Да и кодировать лучше в q-mode, он и не раздувает, и оптимизаций соотношений в последний год-два там более чем.
> Переходи на VVenC, отличный кодек, ощутимо превосходит libaom.
В маркетинговом булшите в основном. Фраунхофер никогда не умел в софт, а остальным это нафиг не надо. А вон то еще потом можно выложить в веб, на свой сервак даже.
А троллинг патентных троллей 80 уровня - это врубить HTTP сервак встроеный в VLC на ипаде, и точку доступа - и раздать оттуда мувики в AV1 андроидам вокруг, во.
> И быстрее/эффективней на среднем/быстром пресете.
Кодировать таким кодеком в быстром пресете это вообще бессмысленно и беспощадно. Впрочем ожидать от фанов поделий имени фраунгофера каких-то разумных идей... эээ.... :)))
> И для начала, x265 это поделка от индусов без определённой функциональности формата H265,
В 265 вообще с функциональностью потока - небогато.
> я знаю точно, что как минимум референсный кодер картинку ощутимо лучше выдавал.
Референсные кодеры у исы всегда были кусками бесполезного крапа и заброшкой. А с 266 по сути один фраунгофер напрягается, который рискует совсем без денег остаться - вот и пытается суетиться. Но в софтострое они - никто. И звать никак. Они эксперты по стрижке купонов за патенты, нормально софт писать - не их профиль!
бредни опеннетовцев, рулонами на вес.
> бредни опеннетовцев, рулонами на вес.А в чем бредни то? В 265 нет глобальной компенсации движения и чего либо сравнимого с CDEF. Да и CFL он вроде не умеет и "инноваторы" на службе патентных троллей собезьянили что-то сравнимое только в 266, увы и ах. Это тот случай когда кое-кто много хочет но мало получит. Крутой облом для сразу 2 групп патентных троллей, кроме пары производил soc и издыхающего направления зомбоящиков - остальные не занесли. Так что повторить банкет с 264 малость не вышло. И с 266 вероятно будет такая же фигня. AOM конкурирующая группа, к такому бзобразию патентные тролли готовы не были совсем никак.
Так что как видишь - кнутователи своих придворных ученых кнутуют эвона как, непойми что релизят пачками, а толку то? Какие там EVC, VVC, WTFVS - у них просто истерика релизов. Момент упущен а лучшие технологии появляются теперь не там.
> издыхающего направления зомбоящиковА вот и экспертное мнение подъехало.
Ну и в чем ваша проблема, сравнивать AV1 со стареньким H.256 11-ти (!!!) летней давности и жаловаться, что там чего-то нет? Здравый смысл есть или нет? С 2017 года H.256 развивается, 4 года уже как финализирован стандарт, а вы ради выгораживания более слабого кодека манипулируете сравнениями.Свежие андроид-боксы H.266 умеют? Умеют. Аппаратные декодеры в видяхях уже подтягиваются, вон Интел обеспечил, нвидия и амд вскоре будут (они и с AV1 до последнего тянули - в прошлом году собирал систему на Ryzen 5600G, там по-прежнему никаким AV1 и не пахнет). Это не бесплатная подачка от гугла как AV1, тут реальные корпорации за стандартом стоят, а улучшения картинки того стоят.
Исправление - "со стареньким H.265". Номерные стандарты конечно это тот еще адок, в маркетинговом плане AV1 однозначно более удачное название.
> SVT-AV1 FTWЭээ вы собрались огреть себя эксплойтом прямо в кодировщике? А в качестве декодера libaom никто и не юзает - какой-нибудь dav1d быстрей в разы потому что там оптимзации декодера лучше.
Видео посмотрел на сайте - взломали
это декодирование
он пока читал, в паник выпал, не дочитав
Знакомая ситуация
> Видео посмотрел на сайте - взломалиИ много браузеров декодируют видео именно через ЭТИ либы? В libaom декодер - вообще до кучи, он не сказать что сильно оптимизированый. Поэтому видео через него смотрели разве что на заре становления формата, эн лет назад. Сейчас даже ffmpeg какой в популярных дистрах скорее через dav1d будет его гнать. И все остальные в общем то тоже - потому что сильно шустрее.
уяк, уяк и в продакшен, уж в таких то функциях парамы надо проверять
Поправочка: в Масс Продакшен всему миру. А мы тестируем перетестируем что ни адин пук реквест без сиай не прошёл, а потом на помойку.
Вроде как банальщина не? Засунуть большой номер в парамы
> уяк, уяк и в продакшен, уж в таких то функциях парамы надо проверятьИ только middle finger developer'ы лучше всех знают как надо. Ну так напиши пару кодеков, покажи нубам мастеркласс? А, погоди, на go с его gc получится дикое тормозилово жрущее память, с скоростью 20% от даже libaom неоптимзированого? Вон там в фуксии уже блеснули - так что проект по сути был порубан при первом намеке на просадку экономики.
> Ну так напиши пару кодеков, покажи нубам мастеркласс?О, т.е. чтобы осознать, что входные данные нужно валидировать нужно пару кодеков написать?
А то думал этому на первом курсе прикладной учат.
> О, т.е. чтобы осознать, что входные данные нужно валидировать нужно пару кодеков
> написать?Ну так все такие умные - задним числом. На опеннете. Так, затыкая вулн в другом проекте, где тоже лопухи входные данные не...
> А то думал этому на первом курсе прикладной учат.
А что за курсы такие продвинутые? :)
> А что за курсы такие продвинутые? :)Это уровень школьной информатики современной - отреагировать на некорректные параметры.
Но я понимаю, что в экосистеме, где rm -rf был долго мемом, это всё без защит от дyрaкa, ведь кругом одни гении-самоучки.
В элементарном тестировании подразумевается, что после сложения предельных значений будет переполнение.
>> А что за курсы такие продвинутые? :)
> Это уровень школьной информатики современной - отреагировать на некорректные параметры.Что-то не похоже - результаты этого хде и в чем проявляются?
> Но я понимаю, что в экосистеме, где rm -rf был долго мемом,
> это всё без защит от дyрaкa, ведь кругом одни гении-самоучки.Куда уж нам, д-ракам, до middle finger dev'ов, чай то пить. Только что-то CVE в вашем добре немеряно. Как же так? И еще пару кодеков по вашим лекалам подгоните? Раз уж вы рассказываете за экосистемы - покажите чего ваша экосистема может. А, написать тормозной драйвер фата и зафэйлить в результате проект? Сделав крутую ОС, убийцу всего, на двух фоторамках? Это тема.
> В элементарном тестировании подразумевается, что после сложения предельных значений будет
> переполнение.Спасибо капитан очевидность!
> А что за курсы такие продвинутые? :)Прикладная математика.
Вроде и не супер продвинутый курс.
> Прикладная математика.
> Вроде и не супер продвинутый курс.Ну для тебя возможно и не сильно продвинутый, а вот для местных птуʼшников это огого!
Хотя мне кажется, что теор.физика гораздо сложнее.
На прикладной хоть примеры использования есть, а там вообще мрак)
>> А что за курсы такие продвинутые? :)
> Прикладная математика.
> Вроде и не супер продвинутый курс.А зачем это все прикладникам от математики, интересно? Это больше по линии информационной безопасности скорее. Хотя так то похвально конечно.
> А зачем это все прикладникам от математики, интересно? Это больше по линии
> информационной безопасности скорее. Хотя так то похвально конечно.Так у прикладников почти пополам теоретическая математика и программинг.
Нам и ассемблер преподавали, и курс про основы криптографии был.ИнфоБезы думаю не будут закапываться в то, как работает AES, схему эль гамаля или учить теоремы по элиптическим кривым.
> целочисленному переполнению и записи в область вне границ буфера при обработке слишком больших значений в некоторых параметрах1. параметры проверять - это дело не барское
2. выходит за границы буфера - ha-ha-classic
3. aom_image.c
надо сразу на JS писать было и запускать под Deno
почему не bun
да хоть жбан, всё равно найдутся однокнопочники, которые не видели проектов с десятками миллионов строк кода, готовые все переписывать раз в квартал
> надо сразу на JS писать было и запускать под DenoПерефразируя известную фразу - это не Deno, это denO!
что еще за DNO?
превосходный человек, ты бы так никогда не сделал, но истинна в том, что лишь теоретически
Перепиши на zig.
Ни один из языков не проверяет математическое переполнение.
В Расте есть проверки в релизных билдах. Если нужна сумма с переполнением, то есть специальные функции.
В расте нет проверки переполнения переменной в релизных билдах. Только в девовых и всяких левых.
Можно включить, это лишь опция профиля, которая по дефолту в релизе false[profile.release]
overflow-checks = trueAlso никто не мешает описать свой числовой тип, и использовать перегрузку операторов
Проблема разве что с проверкой на переполнение в том, что это нужно иметь NaN-подобное значение, что хуже чем явно использовать checked методы где положено
> Можно включить, это лишь опция профиля, которая по дефолту в релизе false
> [profile.release]
> overflow-checks = trueНу та и сишку с asan и ubsan можно с таким же успехом релизнуть, тоже поймает. Но за такую либу кодека тебя все же замесят с гуано за перфоманс. Libaom и так мягко говоря не быстрый. Тормознуть его этим еще разика в 3 в жесткой математике как раз, по всей плозади? Ну, э, упс, это будет позор какой-то. Вы не доживете до транскодирования более-менее жирного мувика таким манером.
А так есть кодировшик на хрусте - но кроме ваусупербыстроекодирование он ничего интересного из себя не представляет и в целом оказался всем похрен. Особенно когда оказалось что кодек это вам не быстренько хайпануть, а еще и пахать надо - и долго - упрямо фикся взбрыки алго и улучшая годами. Это не тот случай когда срубил хайпа по быстрому и в кусты. Ну и где оно в результате такое красивое? А, не нужно никому нафиг? :)
О, как обычно когда сишники обделались, началось куракеканье про перформанс.Тебе мало уязвимости "10 из 10, подразумевающий возможность эксплуатации при обработке в приложениях, использующих данную библиотеку" ?
Зато бытстро! (с)
> О, как обычно когда сишники обделались, началось куракеканье про перформанс.Так у хруста и релиз-дебаг ровно тот же tradeoff что C vs ubsan какой. Ну вот нет в природе халявного метода в рантайме чекать переполнение целых, для этого новых команд проца надо в поток добавить с проверкой флагов математики, блин.
Лишние команды - весьма хреновы для перфоманса в тугих циклах с интенсивным процессингом потока данных. Хруст по этому поводу ничего нового изобрести не сможет. Как и все остальные. У вас либо есть рантайм проверки либо нет.
Для каких-то частных случаев можно посчитать в компил тайм. Но это не работает для произвольных входных данных.
> Тебе мало уязвимости "10 из 10, подразумевающий возможность эксплуатации при обработке
> в приложениях, использующих данную библиотеку" ?
> Зато бытстро! (с)А вот очередной адепт серебряных пуль... интересно, а почему при запросе rust вон там уже сотни CVE появляются? Может, ценность пуль немного преувеличена? Вдруг это не некромансия?! Будет как в анекдоте - "тогда крутите свои, они вам больше не понадобятся"
> Ну вот нет в природе халявного метода в рантайме
> чекать переполнение целых, для этого новых команд проца надо в поток
> добавить с проверкой флагов математики, блин.Вот только эти флаги как раз у нас всегда проставляются и не сбрасываются просто так, а сами процессоры суперскалярны, что чаще всего приводит к тому что амортизированная стоимость таких проверок нулевая.
Да, если на каждый чих делать проверку и возврат ошибки то это будет дорого, поскольку лишние ветвления в горячем коде могут SIMD помешать, однако в Rust абстракции такие, что переполнения можно пачками ловить, даже вот такой пример далеко не хорошего кода компилируется в пару SIMD операций и маску
// К каждому элементу входящего массива нужно times раз прибавить value, при успехе элемент
// должен быть Some(value), при неуспехе None
fn add_times<const N: usize>(inputs: [u32; N], value: u32, times: u32) -> [Option<u32>; N] {
let mut inputs = inputs.map(Some);
for _ in 0..times {
inputs = inputs.map(|input| input.and_then(|input| input.checked_add(value)));
}
inputs
}В данном случае оно конечно должно было в идеале посчитать value.checked_mul заранее, но к сожалению пока не соображает
Однако оно понимает что можно собрать флаги в маску и scatter конечные значения по маске, оставляя промежуточные как есть (Rust ведь стандартизирует что при математике там переполнение, а не UB и призыв кракена. Хотя тут это возможно и не играет роли)А если не заставлять компилятор мучаться со сложным представлением в памяти, и занулять/saturateить переполнения (что в реальном коде чаще всего и происходит)
fn add_times<const N: usize>(mut inputs: [u32; N], value: u32, times: u32) -> [u32; N] {
for _ in 0..times {
inputs = inputs.map(|input| input.checked_add(value).unwrap_or(0));
}
inputs
}То тут всё вовсе к развёрнутому циклу с cmovbами (conditional move on flag) свелось, что для суперскалярного процессора тривиальная задача, и value*times заранее посчитало
>> Ну вот нет в природе халявного метода в рантайме
>> чекать переполнение целых, для этого новых команд проца надо в поток
>> добавить с проверкой флагов математики, блин.
> Вот только эти флаги как раз у нас всегда проставляются и не
> сбрасываются просто так, а сами процессоры суперскалярны, что чаще всего приводит
> к тому что амортизированная стоимость таких проверок нулевая.Ну и бред. "Слышал звон, да не знаю где он". Ну в целом ничего другого от раст-о-мана я не ожидал.
> Вот только эти флаги как раз у нас всегда проставляются и не
> сбрасываются просто так, а сами процессоры суперскалярны, что чаще всего приводит
> к тому что амортизированная стоимость таких проверок нулевая.Черта с два. В кодеках, крипто и прочей интенсивной математике это как раз очень сильно вылезает. Блоки выполнения и без этого там были прогружены по максимуму - так что дополнительные инструкции все сильно клинят. Если инструкций стало больше - значит и времени на их выполнение тоже больше. Чудес не бывает.
> Да, если на каждый чих делать проверку и возврат ошибки то это будет дорого,
И это именно ТОТ случай. Кодеки состоят из математики чуть менее чем полностью, и там будет облом и просадка в разы.
> вот такой пример далеко не хорошего кода компилируется в пару SIMD
> операций и маскуВ кодеках как правило - свой simd или асм. Писаный руками а потом СИЛЬНО лучше компилерского. При том в тугих циклах это очень важно.
> В данном случае оно конечно должно было в идеале посчитать value.checked_mul заранее,
Это все как относится к тому что кодеки делают? Этот сегмент кода имеет что-то общее с поведением кодеков? Или чего? Что в нем обшего с кодеками?
> То тут всё вовсе к развёрнутому циклу с cmovbами (conditional move on
> flag) свелось, что для суперскалярного процессора тривиальная задача, и value*times заранее
> посчиталоРазворот циклов тоже обоюдоострая штука и далеко не всегда дает сейчас преимущества, как раз из-за суперскалярности с 1 стороны и выноса кеша и более сильной нагрузки на шины жирным кодом с другой.
> Можно включить, это лишь опция профиля, которая по дефолту в релизе false
> [profile.release]
> overflow-checks = true
> Also никто не мешает описать свой числовой тип, и использовать перегрузку операторов
> Проблема разве что с проверкой на переполнение в том, что это нужно
> иметь NaN-подобное значение, что хуже чем явно использовать checked методы где
> положеноОтличное предложение положить производительность rust на уровень интерпретаторов.
Вообще раст-о-маны веселые ребята - по обстоятельствам отключают проверки получая производительность сравнимую с С++ и включают проверки когда необходимо показать якобы безопасность. И то и другое вместе никогда не бывает..
> В расте нет проверки переполнения переменной в релизных билдах. Только в девовых и всяких левых.Во-первых оно отменяется для релиза только в runtime checks. Статические проверки остаются, тк не влияют на производительность.
Во-вторых, а что происходит если оно переполняется?
В расте у тебя идет однозначное поведение.
А в других ЯП у тебя может быть реально "все что угодно", в зависимости от компилятора, его версии, желания левой пятки создателя компилятора, фазы луны...
> Во-первых оно отменяется для релиза только в runtime checks. Статические проверки остаются,
> тк не влияют на производительность.В сях тоже варнинги на это сделали в современных компилерах. А статические анализаторы ловят дяже и просто "потенциально кривой код".
> Во-вторых, а что происходит если оно переполняется?
С asan/ubsan прога по дефолту вылетает с ошибкой. Но вообще настраиваемо.
> В расте у тебя идет однозначное поведение.
> А в других ЯП у тебя может быть реально "все что угодно",
> в зависимости от компилятора, его версии, желания левой пятки создателя компилятора,
> фазы луны...Компиляторов так то на этом глобусе не сильно дофига. Основные 2 из них умеют ASAN/UBSAN примерно одинаково. Ну и если возвращать фавор то в альтернативной реализации Rust в виде gccrs вообще borrow checker недопилен.
Специальные функции для суммы с переполнением можно использовать в любом языке.
И конечно без монад функции для суммы с переполнением использовать удобно, а потому используются они вездеint a = ...;
int b = ...;
int result;
if (__builtin_add_overflow(a, b, &result)) {
return ERR_OVERFLOW;
}
> И конечно без монад функции для суммы с переполнением использовать удобно, а
> потому используются они везде
> int a = ...;
> int b = ...;
> int result;
> if (__builtin_add_overflow(a, b, &result)) {
> return ERR_OVERFLOW;
> }Если вы будете такое делать в видеокодеке, его перфоманс провалится туда где не светит солнце. А на современные кодеки и так бочку катят что они тормозные дочерта. Тормознуть их еще в несколько разиков можно конечно - но кто ими тогда пользоваться будет и на каком хардваре?!
>[оверквотинг удален]
>> int b = ...;
>> int result;
>> if (__builtin_add_overflow(a, b, &result)) {
>> return ERR_OVERFLOW;
>> }
> Если вы будете такое делать в видеокодеке, его перфоманс провалится туда где
> не светит солнце. А на современные кодеки и так бочку катят
> что они тормозные дочерта. Тормознуть их еще в несколько разиков можно
> конечно - но кто ими тогда пользоваться будет и на каком
> хардваре?!ну надо же всяким производителям CPU денежку как-то зарабатывать. раст-о-маны 99% у них на зарплате.
> В Расте есть проверки в релизных билдах. Если нужна сумма с переполнением,
> то есть специальные функции.Вообще-то в дебажных. И тормозит оно так что в релизной версии кодека ты это явно не захочешь.
Если сильно хочется - можно и из сишки это сделать, врубив asan и ubsan. Вот только нахрен вам кодек с производительностью 20% от оригинала? Математика от лишних проверок скопытится и при том именно в критичном ее куске, увы и ах. Там где все это в разы перфоманс угрохает.
А нахрена тебе кодек который дырявее чем дурьшлаг?
Причем просто от запуска жабаскрипта?Или ты просто нуддист и светить голым задом на весь интернет не только не стыдно, но даже почетно?
> А нахрена тебе кодек который дырявее чем дурьшлаг?Для начала 99.9% мувиков которые я могу транскодировать вполне добронамеренные и с известным происхождением. Ну там камера гаджета какого-нибудь. Меня будет хакать камера смартфона чтоли?
> Причем просто от запуска жабаскрипта?
Не очень понимаю как именно JS у меня сможет вообще с libaom вообще контактировать. Декодируется оно если что совсем другими либами. С livbvpx - ну там еще смотреть надо что кто декодирует и насколько это эксплойтабельно.
> Или ты просто нуддист и светить голым задом на весь интернет не
> только не стыдно, но даже почетно?Нет, я просто считаю что с практической точки зрения вот именно эксплуатировать, именно это, именно так - будет довольно душновато. Особенно в моих конфигурациях.
А если вдруг кто-то каким-то чудом все-же сможет, браузер не умрет, и даже песочницу пробьют... ну... окей, я откачу виртуалку на снапшот, накачу апдейты, переснапшочу уже с ними. И чего?
> А нахрена тебе кодек который дырявее чем дурьшлаг?
> Причем просто от запуска жабаскрипта?
> Или ты просто нуддист и светить голым задом на весь интернет не
> только не стыдно, но даже почетно?Дырявый кодек не нужен никому, поэтому для написания качественного кода надо уметь пользоваться головой, а не перекладывать все на компилятор, оставляя в голове вакуум. Так как проблема сама интересная - с неопределенным поведением.
Сидит раст-о-вщик дебажит с проверкой переполнения, вроде все нормально, при пустой голове сценарий отработал. А в реальном мире, в продуктиве бах и вывалилась идентичная ошибка, так как внезапно появились не предусмотренные спонтанные пики обусловленные какими-либо ошибками в преставлении или анализе исходной информации. А такое сплошь и рядом при математике/анализе больших объемов данных.И ВНЕЗАПНО - та-же ошибка с переполнением с БЕЗОПАСНЫМ растом...
> Так как проблема сама интересная - с неопределенным поведением.В расте поведение определено.
> оставляя в голове вакуум
Пока что вакуум в голове у забивших на проверки сишников.
> та-же ошибка с переполнением
Ошибка может и будет. Но если бы ты прочитал чуть дальше, то заметил бы, что сама CVE происходит не из-за overflow, из-за "записи в область вне границ буфера".
И в расте у тебя упадет аппа с указаним прям строчки где упало.
Неприятно конечно, но в сишке мы получаем дырень 10 из 10 и выполнение произвольного кода.
Абсолютно сравнимые последствия)))
Кроме Rust по дефолту в дебаге, и через методы на числах {checked,saturating,wrapping}_{add,sub,mul,rem}[_signed] всегда
В нормальных языках переполение обычно не проверяется в релизе, но проверки можно включить.
Но главное что поведение хотя бы определено.
А не как в некоторых, где налепили UB для signed int.
> В нормальных языках переполение обычно не проверяется в релизе, но проверки можно
> включить.
> Но главное что поведение хотя бы определено.
> А не как в некоторых, где налепили UB для signed int.После включения таких проверок в продуктиве - сам полученный продукт не нужен будет никому, вместе с Растом.
Еще в древних версиях С/С++ можно было поставить опции компиляции проверки на переполнение
Опасно для браузеров, но нет. Наверное.
Ты думаешь им сильно хочется сказать "Мы в д###е!" (с) ?
В нашем браузере уязвимости могут быть "эксплуатированы через открытие в браузере специально оформленной страницы, вызывающей JavaScript-функции для кодирования видео, или через манипуляций с WebRTC"
Теперь 100500 наших пользователей должны сменить пароли, банковские карты и номер страхового полиса.Естественно они будут тянуть время и рассказывать все-не-так-однозначно... а там и про новость забудут)
> В нашем браузере уязвимости могут быть "эксплуатированы через открытие в браузере специально
> оформленной страницы, вызывающей JavaScript-функции для кодирования видео, или через
> манипуляций с WebRTC"WebRTC вообще лучше всего отключать нахрен. Целиком.
При кодировании опасно. Webrtc можно спокойно отключить, если не используешь. Для звонков отдельный профиль, к примеру, но обычно там ведь электрон какой-нибудь.
> При кодировании опасно. Webrtc можно спокойно отключить, если не используешь. Для звонков
> отдельный профиль, к примеру, но обычно там ведь электрон какой-нибудь.Более того - а это вообще эксплойтабельно? У вас в системе камера наврет браузеру про большой фрейм? Или как это эксплойтом долбать на практике?
>> При кодировании опасно. Webrtc можно спокойно отключить, если не используешь. Для звонков
>> отдельный профиль, к примеру, но обычно там ведь электрон какой-нибудь.
> Более того - а это вообще эксплойтабельно? У вас в системе камера
> наврет браузеру про большой фрейм? Или как это эксплойтом долбать на
> практике?Об том и речь, гугл сказал что у них не воспроизводится, значит можно смело говорить что пароли от мира танков в безопасности. А вот положить кому-нибудь бэкенд, как это раньше любили посредством гзипа или гд/имагмагик - это весело.
> Об том и речь, гугл сказал что у них не воспроизводится, значит
> можно смело говорить что пароли от мира танков в безопасности. А
> вот положить кому-нибудь бэкенд, как это раньше любили посредством гзипа или
> гд/имагмагик - это весело.Гугле - похрен. Они писали как это у них сделано. Работает в изолированых compute виртуалках, по сути без сети, с таймаутами, так что даже если что - ну и что вы им сделаете? Чуть подкрутите метрику завядших виртуалок? Они ужасно расстроятся, конечно. Ну, заблочат пару проблемных аков. Будете сильно настаивать - окей, для вашей подсети придется распознавать много светофоров и велосипедистов до того как вам дадут сделать акк, залить мувик и проч.
Вы утратили контекст. Комментарий был исключительно в контексте боязни уважаемого Анонима выше что через его браузер украдут его пароль от его мира его танков. Соответственно, я указал на то что у него, как у пользователя дефолтного браузера нет причин для беспокойства. Его мир его танков в безопасности :)А вот какой-то сферический бэкенд в вакууме пошатать могут. Не гугловый бэкенд... откуда Вы это вообще взяли?
> приводят к целочисленному переполнению при расчёте смещений и размеров буферовПрекрасная, эталонная реализация, написаная лучшими бракоделами!
Действительно, зачем проверять входные данные?)
В общем, типиКАЛ Си)))
> В дистрибутивах уязвимости пока остаются неисправленными (Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, FreeBSD).Ну как бы:
lsb_release -a
LSB Version: :core-5.0-amd64:core-5.0-noarch
Distributor ID: Fedora
Description: Fedora release 40 (Forty)
Release: 40
Codename: Fortyrpm -q libaom
libaom-3.9.0-1.fc40.x86_64
Ну как бы бета-тестеры бета дистрибутива Red Hat не интересны. А так держи вкурсе ога
Доктор сказал нет значит нет.
Их не устраивал MPEG-2
А тебя всё еще устраивает первопень?
Лошадка?
Палка-копалка?Намекну, что это называется "прогресс".
Жаль что мимо некоторых он проходит.
> "прогресс"Ну хоть в кавычках написал. Что в целом позволяет оценить твой пост как сарказм и одобрить его.
> Ну хоть в кавычках написал. Что в целом позволяет оценить твой пост как сарказм и одобрить его.В целом кавычки используются для обозначения цитат, отсылок, названий и терминов.
Но если для тебя это сарказм - можешь сидеть на коредвадуо и дальше)
> можешь сидеть на коредвадуо и дальшеСпасибо, что разрешил. Для моих задач даже Core 2 Quad будет с запасом. Нагрузка редко превышает даже 50%. В игры не играю и виртуалки по 100500 штук не запускаю.
> Спасибо, что разрешил. Для моих задач даже Core 2 Quad будет с
> запасом. Нагрузка редко превышает даже 50%. В игры не играю и
> виртуалки по 100500 штук не запускаю.Да наздоровье, только вот мы не будем MPEG2 использовать. Хотя-бы потому что занимает дофига места при неважном качестве, и через существующие каналы интернета в реалтайме не пролезает.
И то и другое - фатальные недостатки для видеокодека, кстати.
> мыКто мы? Отучайся говорить за всех. А то что твои аргументы, мягко говоря, несостоятельны, даже лень объяснять.
> Кто мы? Отучайся говорить за всех.Те кто просто запускает ютуб и просто используют AV1)
> А то что твои аргументы, мягко говоря, несостоятельны, даже лень объяснять.
Потому что ты просто слился?
Разве у MPEG 2 нет проблем с быстродвижущимися объектами и последующим распадением на квадратики?
А для решения придумали костыли в виде deblocker'ов.
> Кто мы? Отучайся говорить за всех. А то что твои аргументы, мягко
> говоря, несостоятельны, даже лень объяснять.Да практически все нормальные современные люди. Всякие извращенцы с пнем 2 таки - жесткая маргинальщина. У большинства людей тупо нет привода для DVD.
А больше мпег 2 нигде особого смысла не имеет. Он убог донельзя. Только YUV с subsampling'ом, фиксированные GOP'ы и структура I/P/B групп, отсутствие намека на поддержку RGB и HBD означают что в идеальную картинку он не может принципиально.
Т.е. скажем скринкаст с компа в ЭТОМ сделать можно - но выглядеть будет ужасно. И сколько битрейта не дай - не поможет. Этот кодек принципиально не способен в "visually lossless". Мерзость для кодирования "телевизионного качества" (и контента).
DVD крутится, стирим дропится
> Их не устраивал MPEG-2Вам никто не запрещает пользоваться MPEG2 если это для вас офигенно работает. И на работу можете на лошади подруливать. Жаль что конюшни из фавора выпали, а на заправках овес не предлагают.
А мпег-2 может закодировать мои видео 4к хдр?
> А мпег-2 может закодировать мои видео 4к хдр?Конечно!
Вопрос в том что получится на выходе после разкодирования.
Но для адептом мпега это не так важно)
Но ведь эти кодеки декодируются хардварно на камнях уже лет 10 минимум и браузеры настраиваются на va-api и vpdau?
Кора дуба не позволяет.
> Кора дубаУ меня даже Full HD работало с VP9 без выпада кадров на однопоточном 4 пнe (!) с GT 1030. Так что гaзифицируй лyжи где-то в другом месте.
Удивительно, видео карта 2016г умеет в Full HD! Наверно всё дело в 4м пне! (НЕТ)
Лучше расскажи как ты подружил 4ый пень с PCI express, фантазёр.
Вы правда ни разу Pentium 4 на LGA775 не видели?
> Вы правда ни разу Pentium 4 на LGA775 не видели?Это не чистый эксперимент. Зачем P4 5xx, когда есть нормальные 478 процы с EM64T и нормальные платы на DDR2 с 478 :)
> Удивительно, видео карта 2016г умеет в Full HD! Наверно всё дело в
> 4м пне! (НЕТ)
> Лучше расскажи как ты подружил 4ый пень с PCI express, фантазёр.У меня третий пень с NVME NAND SSD дружит.. а XT с BluRay приводом... и это хотя бы чуть-чуть необычно, а плат с 478 и PCI-E как бы навалом. От экзотики на G31 от "брендов", до асроков VIA.
Не декодируются.На топовом телефоне двухлетней давности Snapdragon 8 Gen 1 - не имеет аппаратного декодера.
Nvidia RTX 2060 2019 года - не имеет декодера.
Ryzen 5 5600G выпущен 3 года назад - не имеет декодера.
Вы о чем вообще? Мы не про MPEG-2, а про совеременный AV1. У меня знакомые покупают телефоны-среднячки (Snapdragon 685 и прочее) - в большинстве современных midrange телефонов нет декодера AV1. В топовых за последний год есть, в некоторых midrange уже тоже есть, в тех что пониже классах и бюджетках - нет. Берем последний Redmi Note например (Xiaomi Redmi Note 13 4G) - нет декодинга AV1, только софтварно с тормозами и в низком разрешении.
Такую ошибку может допустить какой-нибудь малолетний джун, но никак не профессионалный программист, который смог написать аж целый кодек. Так что явно видно, что это очередной замаскированный под ошибку бэкдор. Впринципе, именно для этого и продвигают новомодные кодеки, ибо старые уже изучены вдоль поперёк и полноценно работают без "ошибок"
> Такую ошибку может допустить какой-нибудь малолетний джун, но никак не профессионалный
> программист, который смог написать аж целый кодек. Так что явно видно,
> что это очередной замаскированный под ошибку бэкдор. Впринципе, именно для этого
> и продвигают новомодные кодеки, ибо старые уже изучены вдоль поперёк и
> полноценно работают без "ошибок"Абсолютная глупость написана, именно малолетним джуном. Именно такие ошибки основанные на анализе/математике больших объемов данных, мало того что фактически трудно предсказуемы, они еще и катострофически сложны в воссоздании. Алгоритм может работать абсолютно нормально, но при появлении определенной последовательности чисел, может быть даже единственной, появляется некий экстремум, обусловленный ДА ДАЖЕ оптимизацией математики компилятором. И в реальном мире, даже для профессионального программиста - такие ошибки это АД.
Но тебе то это не известно, так как кроме аналогов ХеллоВорлд или сложения строчек в виде a = b+c ты ничего не написал.
Поправка, ан нет, оказывается раст-о-маном. Но я тебе открою тайну - в продуктиве твой раст не защитит тебя от этой ошибки. И когда на расте мы увидим что-то реально сложно-математическое - мы увидим появления такого класса ошибок и переполнений БЕЗОПАСНОГО раста, которые четко ограничат сферу применения раста в целом.
А когда ты попытаешься в продуктиве включить проверку этого, то твоя реализация тупо не нужна будет никому по причине увеличения времени выполнения раз в 10.
bOOster, ну хватит уже жиденько прям по всей теме!> ошибки основанные на анализе/математике больших объемов данных
Какая математика?! Ты их фикс вообще смотрел?
https://aomedia.googlesource.com/aom/+/8156fb76d88845d716867...
+ /* Impose maximum values on input parameters so that this function can
+ * perform arithmetic operations without worrying about overflows.
+ */
+ if (d_w > 0x08000000 || d_h > 0x08000000 || buf_align > 65536 ||
+ stride_align > 65536 || size_align > 65536 || border > 65536) {
+ goto fail;
+ }https://aomedia.googlesource.com/aom/+/19d9966572a410804349e...
+ s = s * bit_depth / 8;
+ if (s > INT_MAX) goto fail;Они вообще не проверяли что у них получилось!
Это типичный б#дл@кодинг.
> Но я тебе открою тайну - в продуктиве твой раст не защитит тебя от этой ошибки.Ты понимаешь что проблема не в ошибке?
А в последствиях.
Если бы при попадании специально оформленных данных либа просто падала, ну ладно пусть будет падать весь браузер - это было бы очень неприятно, но не было бы дырени на 10 из 10.Но нет, у нас же самые ылитные пограммисты используют кривой инструмет, который позволяет выйти за пределы буфера и допустить уязвимость через открытую страничку в браузере.
А когда им говорят "ваш инструмет овно, у вас UBшек как блох на собаке", то они бычатся и начинают сьезжать то на перформанс (очевидно на дверях у них замков нету, это же замедляет прохождение двери), то на раст (а он каким тут боком? наовнячили в си коде).
>Подвержен ли Firefox проблеме пока не ясно, так как информация о том, как уязвимость затрагивает конкретные продукты, пока не опубликована.<sarcasm>Молодцы, придерживаются лучших практик</sarcasm>