8 ms·
>Thanks to them being yet another attack vector and funny stuff like on this post, got demoted to optional on C11. Sadly, the C committee doesn't really unders
by option_key 4y ago
>Thanks to them being yet another attack vector and funny stuff like on this post, got demoted to optional on C11.
Sadly, the C committee doesn't really understand what was wrong with VLAs and a sizable group of its members wants to make them mandatory again:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2921.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2921.pdf ("Does WG14 want to make VLAs fully mandatory in C23")
- planede 4y agoWhat's wrong with VLAs is their syntax. It really shouldn't use the same syntax as regular C arrays, otherwise they would be fine, maybe with a scary enough keyword. They are more generic than alloca too, alloca being scoped to the function, while VLAs being scoped to the innermost block scope that contains them.
- pjmlp 4y agoSyntax, no protection against stack corruption,...
- tstanisl 4y agoint A[100000000]; Also has no protection.
- planede 4y agoYou can corrupt the stack without VLAs just fine. What else?
- pjmlp 4y agoWhat about not adding even more ways how we should avoid using C?
- arinlen 4y ago> What about not adding even more ways how we should avoid using C? That's a mute point for C's target audience because they already understand that they need to be mindful of what the language does.
- pjmlp 4y agoThat is like saying if sushi knifes are already sharp enough, there is no issue cutting fish with a samurai sword instead, except at least with the knife maybe the damage isn't as bad.
- Koshkin 4y agoI like your comparison of a C programmer with a samurai.
- pjmlp 4y agoIncluding that most of them end up doing Seppuku on their applications.
- agumonkey 4y agowhile we're hugging them from behind
- phibz 4y agoIt's more like the C programmer is a sushi master. They can make a delicious, beautifully crafted snack. But if the wrong ingredients are used you'll get very sick.
- samatman 4y agoThe difference between the largest sushi knives and a katana is more about who wields them than the blade involved.
- pjmlp 4y ago
- einpoklum 4y agoWith VLAs: 1. The stack-smashing pattern is simple, straightforward and sure to be used often. Other ways to smash the stack require some more "effort"... 2. It's not just _you_ who can smash the stack. It's the fact that anyone who calls your function will smash the stack if they pass some large numeric value.
- saagarjha 4y agoThey can overflow the stack. They cannot smash the stack.
- rhexs 4y agoUseless semantic pedantry at best, but arguable wrong as there isn't some sort of ISO standard on dumb hacking terms.
- saagarjha 4y agoOverflowing the stack gives you a segfault. Smashing the stack lets hackers pop a shell on your computer. They are incredibly different. VLAs can crash your program, but they do not give attackers the ability to scribble all over the stack.
- pjmlp 4y agoUnless they happen to be enjoying kernel space.
- saagarjha 4y agoThere is no difference.
- bjourne 4y ago> Overflowing the stack gives you a segfault. Maybe. If the architecture supports protected memory and the compiler has placed an appropriately sized guard page below the stack. If it doesn't then overflowing the stack via a VLA gives you easy read and write access to any byte in program memory.
- rwmj 4y agoVLAs make it a lot easier to corrupt the stack by accident. Unless you're quite a careful coder, stuff like: f (size_t n) { char str[n]; leads to a possible exploit where the input is manipulated so n is large, causing a DoS attack (at best) or full exploit at worse. I'm not saying that banning VLAs solves every problem though. However the main reason we forbid VLAs in all our code is because thread stacks (particularly on 32 bit or in kernel) are quite limited in depth and so you want to be careful with stack frame size. VLAs make it harder to compute and thus check stack frame sizes at compile time, making the -Wstack-usage warning less effective. Large arrays get allocated on the heap instead.
- chjj 4y agoYou shouldn't be writing C if you're not a careful coder.
- kllrnohj 4y agoHint, that means nobody should be writing C.
- krallja 4y agoWhere is the lie?
- samatman 4y agoAnd if you're a careful coder writing C, you should give the VLA the stink eye unless it's proving its worth.
- pjmlp 4y agoYeah, right. https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... https://research.google/pubs/pub46800/ https://research.google/pubs/pub46800/ https://support.apple.com/guide/security/memory-safe-iboot-implementation-sec30d8d9ec1/web https://support.apple.com/guide/security/memory-safe-iboot-i... Maybe you could give an helping hand to Microsoft, Apple and Google, they are in need of carefull C coders.
- saagarjha 4y agoVLAs are no more unsafe than standard C is for stack corruption.
- jcelerier 4y agothe only result of banning VLAs is to force everyone to use alloca, which is even less safe. exhibit A: https://lists.freedesktop.org/archives/mesa-commit/2020-December/110941.html https://lists.freedesktop.org/archives/mesa-commit/2020-Dece... exhibit B: https://github.com/neovim/neovim/issues/5229 https://github.com/neovim/neovim/issues/5229 exhibit C: https://github.com/sailfishos-mirror/llvm-project/commit/6be7c21b57e4a45b012209974ab9038b679134f5 https://github.com/sailfishos-mirror/llvm-project/commit/6be... etc etc
- tedunangst 4y agoNobody is forced to use alloca, which is not less safe, only equally disastrous. Just use malloc, already.
- jcelerier 4y agoah yes, why didn't I think of it, let me just try: #include <cstdlib> #include <span> __attribute__((annotate("realtime"))) void process_floats(std::span<float> vec) { auto filter = (float*) malloc(sizeof(float) * vec.size()); /* fill filter with values */ for(int i = 0; i < vec.size(); i++) vec[i] *= filter[i]; free(filter); } $ stoat-compile++ -c foo.cpp -emit-llvm -std=c++20 $ stoat foo.bc Parsing 'foo.bc'... Error #1: process_floats(std::span<float, 18446744073709551615ul>) _Z14process_floatsSt4spanIfLm18446744073709551615EE ##The Deduction Chain: ##The Contradiction Reasons: - malloc : NonRealtime (Blacklist) - free : NonRealtime (Blacklist) oh noes :((
- tedunangst 4y agoHere's a nickel, kid. The bullshit about oh my embedded systems doesn't have dynamic memory is bullshit. You either know how big your stack is and how many elements there are, and you make the array that big. Or you don't know and you're fucked. You can't clever your way out of not knowing how big to make the array with magic stack fairy pretend dynamic memory. You can only fuck up. Is there room for 16 elements? The array is 16. Is there room for 32? It's 32.
- chrisseaton 4y ago> wants to make them mandatory again What does 'mandatory' mean? Like if I write a C compiler without them... what are they going to do about it?