And how does Rust help? As far as I know, an integer overflow in Rust panics in debug but just wraps in release (a bad choice in my opinion). Would it help specifically in the code execution part of the exploit?
The key difference is even If an Integer overflows in Rust It still doesn't violate memory safety in safe Rust and therefore doesn't lead to exploitation.
Depends on what kind of exploitation you're talking about -- integer overflows can still cause out of memory conditions and crash the program, which is a denial-of-service vulnerability when talking about webapps.
But yes, memory-save languages like Rust are a massive help protecting against remote code execution. (unless said memory-safe language introduces its own category of RCE vulnerabilities, e.g. deserialization in Java)
The integer overflow issue is only part of the problem. There are a couple underlying issues that make this exploit feasible: certain regexes produce extremely long bytecode, the integer overflow issue, and finally, a double free.
Rust will not protect you against exploding regexes, it will not protect you against integer over/underflows (unless you specifically call safe wrapping methods), but it will protect you against double frees if you use it sensibly (nothing prevents you from breaking the borrow checker and messing up memory if you write an unsafe {} block).
It is not obsolete insofar as it is a good source of Q/A material, which is useful to both humans (directly or indirectly) and bots. The only part of it that is obsolete is the search/query part. If the AI companies had an ounce of decency, they would see no problem injecting money into the platform to continue seeding that Q/A material which they have directly profited from. But investing in a commons is not on the playbook for vulture capitalism.
Thanks for pointing that out, it does explain many things. It's tiring to read about languages and projects like they are some hot shit that makes everything before it obsolete when in reality it's just a different set of trade-offs. We should approach discussions more objectively like your comment does and less like a marketing slide.
> Now all of your allocations during that connection are guaranteed to be freed instead of having to keep track of them individually
And how do you size the arena?
> keep track of them individually
I think this is an exaggeration of the problem. This is what RAII semantics in C++ are for.
> avoiding that kind of invisible code
The invisible code is traded for defer statements right after initialization that are obvious and therefore mostly just noise, and also a problem if you forget to call them. This isn't an issue with RAII. I get the point of not wanting invisible code, but defers don't seem much of an improvement either. A trade-off at best.
Two options: you either say "eh 20MB per request ought to be big enough" and resize it later if you need to. Or you take time to figure out reasonable limits in terms of whatever domain you're dealing with, and return descriptive errors when those limits are exceeded. Maybe you're saying your service supports up to N HTTP headers and M query parameters in the URL and so on. For almost anything there's a limit you can place that's reasonable. Having no limits at all just means the limit is when you run out of memory / disk / whatever.
If you like RAII and C++ just use that though, Zig is an alternative not an upgrade, imo.
The problem is not finding limits, although that does take decent engineering for anything non-trivial. The problem is that a hard limit assumes your requests have a relatively uniform distribution of memory requirements. Otherwise, you are wasting memory. Or you have N limits instead, which just complicates the problem.
Resize: realloc invalidates pointers. If you're saying allocate more chunks and link them, that is technically no longer an arena?
Requesting virtual memory and committing lazily seems a good trade-off except on Windows, which does not allow to over-commit. Somehow I don't find that very satisfying because it relies on the OS and on the hardware to provide virtual memory support. But maybe it's just what it is.
Yup! In C you can mmap out a big anonymous region and then it will only take up actual resident space for pages you use. I'm not sure if Zig exposes this in the stdlib somewhere or if you'd just do it through libc.
If you're doing something like per-request or per-frame arenas you can clear the arena without having to reallocate the whole mapping. And depending how fancy you want to get you can mark the pages unused when you clear the arena so that the OS can reclaim them if needed.
As opposed to allocating a bunch of memory you won't need?
Allocating virtual memory up front and committing lazily might be a good trade-off, until it isn't. So I'm not actually sure and hence why I asked the question.
Not to take away from your point, but client_max_body_size "Sets the maximum allowed size of the client request body." That is different from how much the server/service is allowed to allocate internally to service the request.
Yes, my bad, replied in a hurry. Technically, the arena size will be function involving both the request body size, the response body size, along with the sizes of any intermediate results of processing.
The truth is really a middle ground and the fact that you won't get the design right the first time around until you have built that hardware programming experience and learned from past mistakes. But this statement doesn't make for a good marketing stunt.
I first encountered this behaviour on Linux desktop with Qt QML apps as far back as 2015. For a long time, I thought it was Qt QML ListView's inefficiency and didn't think much of it.
But in recent years, the phenomenon was visible with Dip which was built on rust.
Dip does massive parallel fanout using green threads ('may' coroutines) with work being NUMA pinned (software hash) using a thread per core model.
A default request may span up to _chunk_count_ jobs (default 5k) configurable per request.
Every request (x 5k jobs) from the client on a stress test sees a jump of ~10-20 MB of memory. Sometimes the jumps use large swaths of memory - say 100s of MB and stabilizes for a while only to gradually climb up again later. Rinse and repeat - OOM kicks in and the process crashes.
Many times we thought we were leaking memory somewhere. But armed with the Qt experience a decade ago, we intuited maybe its the allocator - and switched to mimalloc on desktop executable.
Dip's memory, using mimalloc, stabilizes at ~60 MB post request completion no matter how many requests you throw at it.
Pity that on mobiles, more specifically Android, we have to live with the default allocator on even trivial Qt apps let alone embedded Dip. But people have lived with it for at least a decade, so it is what it is.
Thus on mobiles, we just have to be content like everybody else, unable to squeeze every last ounce of performance and efficiency out of the hardware on stress tests ensuring Dip remains "just better :(" :)
There is no "US voting system". Each of the 50 States have their own systems, often several systems, and where there are several systems it's the counties that pick a system that suits them.
I'm confused. Can you explain the exact issues created by this repudiation system practiced by US states? Maybe there's a real issue that hasn't been addressed that I am unaware of.
Which is not to say that they are necessarily auto-vectorizing. You know wassup when you see vaddsd instead of vaddpd. And ideally you'd use AVX-512 to saturate a modern cache line if you can afford to drop support for the older devices.
reply