Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
17 строка не вывелась потому что застряла в буфере. Если поменяешь \n на endl её будет видно.
12 строка не вывелась потому что до нее управление реально не дошло. Место под фрейм выделилось в самом начале функции (конструкторы всегда срабатывают вовремя, а вот место может выделиться сразу). И вызов << упал от вылета за стек. Ну или прям во время выделения места сработал stack protector, если опция была включена.
Если стек протектор включен: выделил фрейм, протыкал странички до защитной, напоролся неё и упал.
Если стек протектор выключен: выделил фрейм, начал сохранять текущий адрес перед вызовом << и упал. Но мог и не упасть, а писнуть в чужую память. Раз на раз не приходится.
> Что выведет программа, если скомпилировать без оптимизаций и почему?
А это где-то определено? Например что вывод на консоль должен фактически завершиться раньше, чем будет вызвана вложенная функция (program order-то при этом не нарушается, главное только порядок вывода сообщений на сосноль). Без оптимизаций - это не в режиме интерпретатора.
теоретически можно флашить каждый символ (быстро будет работать!), но если ты пишешь не в файл, то ос наверное не обязана вот прямо сразу чото куда-то рисовать
"The hypervisor did not enable mitigations for CVE-2018-3646, CVE-2019-11091, CVE-2018-12126, CVE-2018-12127, and CVE-2018-12130 for virtual machines because HyperThreading is enabled. To enable mitigations for virtual machines, disable HyperThreading."
а ведь было же сказано еще https://www.theregister.com/2018/06/20/openbsd_disables_intels_hyperthreading/
У хороших либ есть стабильные версии, в которых только баги да уязвимости фиксят.
Проблема в том, что это дорого для разраба либы. Особенно если он хочет регулярно выкатывать новые фичи. И многие из них забивают хуй и поддерживают только последнюю версию. И вот тут-то у юзера и начинаются проблемы -- он не может получить фикс без новых фич. Такой версии либы тупо не существует. И никакие локи-хуёки его не спасут.
Я как раз таки за такую модель, когда приложуха по-минимуму зависит от системы. В идеале только от ядра или каких-то очень стабильных либ, как в винде.
Если мейнтейнер снапа/контейнера/статикпроги не умеет в секьюрити, ну, возможно, не стоит его софт юзать?
на винде ничто не мешает тебе ставить редистрибьютибл CRT, а уж во времена до SxS так и вовсе срать в system32
но в целом кульутура шареных либ там меньше, бо нет репозитория
А у меня нет строгого мнения, я вижу плюсы и в одном, и в другом подходе. Но в целом, большинство программистов похоже согласно с тобой, а не с автором
Просто тут я наверное больше смотрю с точки зрения разработчика: отсутствие фиксированных версий может ненароком порвать пердак при невинном pod update
Ну кстати, мейнтейнеры же обычно собирают всё сами, получая от разрабов только сырцы. Т.е. пересобрать контейнеры или снапы им не составит труда. Админ разницы особо не заметит.
Проблема тут в том, что они не хотят и не могут патчить 100500 разных версий библиотеки, которая юзается в этих снапах. Именно поэтому у них так горит от локов на версию. Именно поэтому они хотят иметь всего 1-2 на всю систему.
В случае с openssl это довольно легко т.к. её разрабы понимают что такое поддержка. В случае со скриптопарашей это нереально.
> А с этими вашими локфайлами, докерами, снапами, и прочими "go" он лапу сосет, пока 30 вендоров не обновят либу
Да это пофиг, перелочить все зависимости на пофиксанную версию да пересобрать контейнер/снап -- не такая уж проблема.
Корень зла в том, что такой версии нет. Её физически нет. А свежую пофиксанную воткнуть вместо неё нельзя потому что всё пидорасит. Вот она плата за быструю доставку изменений.
Угу. Но это именно то, что пропагандируют адепты локов: мы не осилили обратную совместимость, поэтому у нас есть одна поддерживаемая версия -- последняя.
MAPTbIwKA # 0
с оптимизацией наверное она выеинет нахуй твой разрыватор, и ничего не разорвет
а без оптимизации может в теории и порваца, не?
bormand # 0 ⇈
На винде должен порваться т.к. chkstk пойдёт протыкивать страницы палочкой.
На прыщах, мне кажется, нет. Просто RSP уменьшится на 200кк, потом вернётся обратно. Надо какой-нибудь лог вывести после разрыватора, тогда порвёт.
MAPTbIwKA # 0 ⇈
*при условии, что компилятор писание это не выкинет нахцй
pps: проверил на прыще, segfault там
bormand # 0 ⇈
Стек протектор сработал:
orq $0x0,(%rsp)
Тоже по страничке протыкивает, получается.
bormand # 0 ⇈
Стек рвётся из-за того, что весь фрейм резервируется сразу, а потом вызывается operator <<.
bormand # 0 ⇈
guest # 0 ⇈
bormand # 0 ⇈
hormand # 0 ⇈
Сделай милость, обидься и уйди, хлопнув дверью.
guest # 0 ⇈
guest # 0 ⇈
bormand # 0 ⇈
12 строка не вывелась потому что до нее управление реально не дошло. Место под фрейм выделилось в самом начале функции (конструкторы всегда срабатывают вовремя, а вот место может выделиться сразу). И вызов << упал от вылета за стек. Ну или прям во время выделения места сработал stack protector, если опция была включена.
MAKAKA # 0 ⇈
Иными словами, я могу разбрасывать автоматические переменные по всему блоку, но указатель стека крутанется сразу?
с89 в этом плане честнее, конечно
bormand # 0 ⇈
Если стек протектор выключен: выделил фрейм, начал сохранять текущий адрес перед вызовом << и упал. Но мог и не упасть, а писнуть в чужую память. Раз на раз не приходится.
bormand # 0 ⇈
Ну это просто оптимизация такая. Нафиг нужны лишние сложения и вычитания, если достаточно одного в начале и одного в конце.
Ничто не обязывает конпелятор делать именно так. И на других всё может быть по-другому.
hormand # 0 ⇈
Сегфолт говорит: "Здравтвуй"
Fike # 0
А это где-то определено? Например что вывод на консоль должен фактически завершиться раньше, чем будет вызвана вложенная функция (program order-то при этом не нарушается, главное только порядок вывода сообщений на сосноль). Без оптимизаций - это не в режиме интерпретатора.
MAKAKA # 0 ⇈
Если ты писнул в буфер, и не влашнул его, а потом упала программа, то гарантий нет
bormand # 0 ⇈
Крестобляди соснули.
guest # 0 ⇈
bormand # 0 ⇈
Как-будто в интерпретаторах этой проблемы с флашем при смерти проги нет. Тоже запросто могут оборвать вывод на середине.
guest # 0 ⇈
bormand # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
А обязан-ли? А если пол байта считал? А если ты пишешь в псевдотерминал? или опхуй?
bormand # 0 ⇈
Хер знает... Я где-то здесь постил багу про усб-ком адаптер, который проёбывал хвост пакета если его закрыть.
guest # 0
"The hypervisor did not enable mitigations for CVE-2018-3646, CVE-2019-11091, CVE-2018-12126, CVE-2018-12127, and CVE-2018-12130 for virtual machines because HyperThreading is enabled. To enable mitigations for virtual machines, disable HyperThreading."
а ведь было же сказано еще https://www.theregister.com/2018/06/20/openbsd_disables_intels_hyperthreading/
bormand # 0 ⇈
Мало было потери пирфоманса от патчей против спектры, осталось добить отключением половины ядер...
3oJIoTou_gui # 0 ⇈
MAKAKA # 0
ко ко ко снап флетпак
ко ко ко го статическая линковка
и тут у гентушника БОМБАНУЛО!!!!!
https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/
guest # 0 ⇈
MAKAKA # 0 ⇈
Fike # 0 ⇈
guest # 0 ⇈
guest # 0 ⇈
Desktop # 0 ⇈
А так хуйня какая-то: не лочьте версии, а то бабайка придёт
MAKAKA # 0 ⇈
чего хуйня?
Вот например вышла новая версия libFOO, в которой залатали уязвимость
В кклассическом юниксе админ обновил либу, и ссыт спокойно
А с этими вашими локфайлами, докерами, снапами, и прочими "go" он лапу сосет, пока 30 вендоров не обновят либу
Я не говорю, что это всегда лучше. Но есть трейдоф определенный
Desktop # 0 ⇈
А если там добавили, убрали и поменяли перделок?
MAKAKA # 0 ⇈
bormand # 0 ⇈
Проблема в том, что это дорого для разраба либы. Особенно если он хочет регулярно выкатывать новые фичи. И многие из них забивают хуй и поддерживают только последнюю версию. И вот тут-то у юзера и начинаются проблемы -- он не может получить фикс без новых фич. Такой версии либы тупо не существует. И никакие локи-хуёки его не спасут.
Desktop # 0 ⇈
MAKAKA # 0 ⇈
сраные модули к сраному вордпрессу с скулинъекциями могут тоже как либы в линуксе распостраняться
bormand # 0 ⇈
Если в либу пролезло какое-нибудь переполнение буфера (на сишке) или sql/eval инъекция (на скриптушне), то совершенно похуй чем она занималась.
Плюс очень много либ работает с недоверенными данными -- картинки, видео, архивы, книжки, сетевые протоколы...
MAKAKA # 0 ⇈
Согласен с оратором, или категорически нет?
bormand # 0 ⇈
MAKAKA # 0 ⇈
за статическую компиляцию и пин депенденсов (лок) а так же за снапы и флетпаки надо давать в ибало, ибо это не секурно
bormand # 0 ⇈
Я как раз таки за такую модель, когда приложуха по-минимуму зависит от системы. В идеале только от ядра или каких-то очень стабильных либ, как в винде.
Если мейнтейнер снапа/контейнера/статикпроги не умеет в секьюрити, ну, возможно, не стоит его софт юзать?
MAKAKA # 0 ⇈
но в целом кульутура шареных либ там меньше, бо нет репозитория
А у меня нет строгого мнения, я вижу плюсы и в одном, и в другом подходе. Но в целом, большинство программистов похоже согласно с тобой, а не с автором
Desktop # 0 ⇈
MAKAKA # 0 ⇈
разрабу вообще приятнее вручную выбрать нужные версии, протестировать всё 20 раз, и ровно их и отдать пользователю
а админу наоборот хочется обновить openssl не трогая разраба
bormand # 0 ⇈
Проблема тут в том, что они не хотят и не могут патчить 100500 разных версий библиотеки, которая юзается в этих снапах. Именно поэтому у них так горит от локов на версию. Именно поэтому они хотят иметь всего 1-2 на всю систему.
В случае с openssl это довольно легко т.к. её разрабы понимают что такое поддержка. В случае со скриптопарашей это нереально.
bormand # 0 ⇈
Да и с крестами в общем-то. Попробуй тот же буст обновить без пересборки всего софта, который его юзает. Не уверен, что это прокатит.
MAKAKA # 0 ⇈
проблему с разными версиями я понял, тут конечно сосат6
Desktop # 0 ⇈
Fike # 0 ⇈
guest # 0 ⇈
а знаешь такую либу -- "glibc"?
https://wiki.postgresql.org/wiki/Locale_data_changes
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20210225/e25fc245/attachment.html
bormand # 0 ⇈
Но блин, что для glibc факап, то для скриптуха на руби или питоне -- образ жизни.
Fike # 0 ⇈
Fike # 0 ⇈
ну естественно, проблема здесь в локалях
bormand # 0 ⇈
Да это пофиг, перелочить все зависимости на пофиксанную версию да пересобрать контейнер/снап -- не такая уж проблема.
Корень зла в том, что такой версии нет. Её физически нет. А свежую пофиксанную воткнуть вместо неё нельзя потому что всё пидорасит. Вот она плата за быструю доставку изменений.
guest # 0 ⇈
>версии нет
это еще бОльший пиздец
bormand # 0 ⇈
Угу. Но это именно то, что пропагандируют адепты локов: мы не осилили обратную совместимость, поэтому у нас есть одна поддерживаемая версия -- последняя.
MAKAKA # 0
guest # 0 ⇈