- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
#include <iostream>
#include <ctime>
using namespace std;
#define SIZE 200000000
struct StackRazrivator {
int data[SIZE];
};
void razorvi() {
cout << "nachinau razrivat\n";
StackRazrivator r;
}
void razrivator() {
cout << "razrivator\n";
razorvi();
}
int main() {
cout << "start" << endl;
razrivator();
return 0;
}
Follow us!
с оптимизацией наверное она выеинет нахуй твой разрыватор, и ничего не разорвет
а без оптимизации может в теории и порваца, не?
На винде должен порваться т.к. chkstk пойдёт протыкивать страницы палочкой.
На прыщах, мне кажется, нет. Просто RSP уменьшится на 200кк, потом вернётся обратно. Надо какой-нибудь лог вывести после разрыватора, тогда порвёт.
*при условии, что компилятор писание это не выкинет нахцй
pps: проверил на прыще, segfault там
Стек протектор сработал:
orq $0x0,(%rsp)
Тоже по страничке протыкивает, получается.
Стек рвётся из-за того, что весь фрейм резервируется сразу, а потом вызывается operator <<.
Сделай милость, обидься и уйди, хлопнув дверью.
12 строка не вывелась потому что до нее управление реально не дошло. Место под фрейм выделилось в самом начале функции (конструкторы всегда срабатывают вовремя, а вот место может выделиться сразу). И вызов << упал от вылета за стек. Ну или прям во время выделения места сработал stack protector, если опция была включена.
Иными словами, я могу разбрасывать автоматические переменные по всему блоку, но указатель стека крутанется сразу?
с89 в этом плане честнее, конечно
Если стек протектор выключен: выделил фрейм, начал сохранять текущий адрес перед вызовом << и упал. Но мог и не упасть, а писнуть в чужую память. Раз на раз не приходится.
Ну это просто оптимизация такая. Нафиг нужны лишние сложения и вычитания, если достаточно одного в начале и одного в конце.
Ничто не обязывает конпелятор делать именно так. И на других всё может быть по-другому.
Сегфолт говорит: "Здравтвуй"
А это где-то определено? Например что вывод на консоль должен фактически завершиться раньше, чем будет вызвана вложенная функция (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/
Мало было потери пирфоманса от патчей против спектры, осталось добить отключением половины ядер...
ко ко ко снап флетпак
ко ко ко го статическая линковка
и тут у гентушника БОМБАНУЛО!!!!!
https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/
А так хуйня какая-то: не лочьте версии, а то бабайка придёт
чего хуйня?
Вот например вышла новая версия libFOO, в которой залатали уязвимость
В кклассическом юниксе админ обновил либу, и ссыт спокойно
А с этими вашими локфайлами, докерами, снапами, и прочими "go" он лапу сосет, пока 30 вендоров не обновят либу
Я не говорю, что это всегда лучше. Но есть трейдоф определенный
А если там добавили, убрали и поменяли перделок?
Проблема в том, что это дорого для разраба либы. Особенно если он хочет регулярно выкатывать новые фичи. И многие из них забивают хуй и поддерживают только последнюю версию. И вот тут-то у юзера и начинаются проблемы -- он не может получить фикс без новых фич. Такой версии либы тупо не существует. И никакие локи-хуёки его не спасут.
сраные модули к сраному вордпрессу с скулинъекциями могут тоже как либы в линуксе распостраняться
Если в либу пролезло какое-нибудь переполнение буфера (на сишке) или sql/eval инъекция (на скриптушне), то совершенно похуй чем она занималась.
Плюс очень много либ работает с недоверенными данными -- картинки, видео, архивы, книжки, сетевые протоколы...
Согласен с оратором, или категорически нет?
за статическую компиляцию и пин депенденсов (лок) а так же за снапы и флетпаки надо давать в ибало, ибо это не секурно
Я как раз таки за такую модель, когда приложуха по-минимуму зависит от системы. В идеале только от ядра или каких-то очень стабильных либ, как в винде.
Если мейнтейнер снапа/контейнера/статикпроги не умеет в секьюрити, ну, возможно, не стоит его софт юзать?
но в целом кульутура шареных либ там меньше, бо нет репозитория
А у меня нет строгого мнения, я вижу плюсы и в одном, и в другом подходе. Но в целом, большинство программистов похоже согласно с тобой, а не с автором
разрабу вообще приятнее вручную выбрать нужные версии, протестировать всё 20 раз, и ровно их и отдать пользователю
а админу наоборот хочется обновить openssl не трогая разраба
Проблема тут в том, что они не хотят и не могут патчить 100500 разных версий библиотеки, которая юзается в этих снапах. Именно поэтому у них так горит от локов на версию. Именно поэтому они хотят иметь всего 1-2 на всю систему.
В случае с openssl это довольно легко т.к. её разрабы понимают что такое поддержка. В случае со скриптопарашей это нереально.
Да и с крестами в общем-то. Попробуй тот же буст обновить без пересборки всего софта, который его юзает. Не уверен, что это прокатит.
проблему с разными версиями я понял, тут конечно сосат6
а знаешь такую либу -- "glibc"?
https://wiki.postgresql.org/wiki/Locale_data_changes
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20210225/e25fc245/attachment.html
Но блин, что для glibc факап, то для скриптуха на руби или питоне -- образ жизни.
ну естественно, проблема здесь в локалях
Да это пофиг, перелочить все зависимости на пофиксанную версию да пересобрать контейнер/снап -- не такая уж проблема.
Корень зла в том, что такой версии нет. Её физически нет. А свежую пофиксанную воткнуть вместо неё нельзя потому что всё пидорасит. Вот она плата за быструю доставку изменений.
>версии нет
это еще бОльший пиздец
Угу. Но это именно то, что пропагандируют адепты локов: мы не осилили обратную совместимость, поэтому у нас есть одна поддерживаемая версия -- последняя.