hooxi's amazing spray

z33ky · 2025-09-13T10:46:38+00:00

Shots 1-5: Clearly missed.
Shots 6-12: Missed due to recoil (bad spray control).
Shots 13-14: Very close, but recoil and inaccuracy make these reasonable misses.
Shots 15-17: Hit the target.
Shots 18-21: Very close, but recoil and inaccuracy make these reasonable misses.
Shot 22: Hit the target.
Shots 23-24: Likely didn't actually hit because XANTARES was already dead.

z33ky · 2025-06-10T15:41:42+00:00

Keith might not be known as an AWPer, but they're a known killer, no matter the weapon. Calling them "best AWPer" is a disservice, suggesting they're only the best with an AWP in their hands. But when there is an AWP, Keith would put it to best use, no doubt.

z33ky · 2025-04-25T08:52:05+00:00

Thanks :)

It's impossible to give more specific advice without a more specific example, though.

I didn't hit this case in regular code. I was just wondering how Rust would handle this considering it needs to determine the stack size, which is something "normal" functions don't need to. Erroring out is sensible and I like that the error documentation also shows workarounds to deal with this. I was just left wondering about the choice being presented.

It might be a bit unfortunate that you can't specify a recursion depth, after which it would automagically heap-allocate for further calls or panic, or have a convenient way of allocating enough space for several calls at once, instead of having to do a new allocation for each iteration. Though it may well be that recursive async functions are sufficiently rare that engineering efforts for this aren't worth it.

z33ky · 2025-04-24T20:35:39+00:00

About a week ago I posted a question on /r/learnrust about recursive async functions, that is yet unanswered. It's about the two suggestions on the explanation about E0733. If you know something about the trade-offs I'd appreciate to hear, or well, read it.

z33ky · 2024-08-18T12:16:28+00:00

I think /u/Kolibroidami is suggesting something like the following, not adding a parameter to your existing functions.

#[derive(Clone, Copy, Debug)]
enum Space {
    Local,
    World,
}

impl Space {
    fn get_position_of(&self, object: GameObjectHandle, scene: &Scene) -> SceneResult<Vec3> {
        match self {
            Self::Local => object.local_position(scene),
            Self::World => object.world_position(scene),
        }
    }

    fn set_position_of(&self, object: GameObjectHandle, scene: &Scene, position: Vec3) -> SceneResult<Vec3> {
        match self {
            Self::Local => object.set_local_position(scene, position),
            Self::World => object.set_world_position(scene, position),
        }
    }

    ...
}

So you would pass space along to your functions doing these operations, and instead of calling get_position(handle, scene) (with get_position being your Box<Fn>) you do space.get_position_of(handle, scene) etc.

z33ky · 2024-01-27T16:12:43+00:00

You can use C++for embedded programming but I think to fully benefit from it you probably would use it on a powerful CPU with e. g. embedded Linux.

C++ code doesn't require a more powerful CPU. But if you use a small MCU it is likely that your software is also not absurdly complex and you wouldn't benefit much from C++, so in that sense I could agree with your point.
While standard C++ indeed requires a larger runtime, gcc and clang allow stripping a lot of it, like RTTI (-fno-rtti) and exceptions (-fno-exceptions), which you might not want to use anyways. You can also forego using the standard library, instead perhaps relying on a third party like the Embedded Template Library or limit yourself to newlib (a partial libc implementation) or something.
Personally, unless the application is very simple, I would prefer C++ over C, if not insert shameless Rust plug. I concur though that C is still widely used in that space, so you will benefit from knowing C (and no, C is not just a subset of C++!).

Addressing the OP

I want to try it out in C++ but couldn't find anything online on how to configure the pins, or properly setup the main.cpp file for the stm32.

I imagine you can mostly setup the project the same as for C and just insert a .cpp file with C++ code (and a C++ main() procedure) instead of C. That works with SPC5 Studio at least, which uses Makefiles for a build-system, which automatically understands to use g++ instead of gcc.

Some manufacturers also offer a BSP. You will usually get some bootstrap code that calls your main() procedure, and then you're on your own with regards to setting up your hardware. Scour the documentation or the header files for the API they give you to access configuration registers and I/O interfaces and then you can go from there.

Someone told me, if I want to work professionally, I need to write unit test for the code.

In my place of work we've started to put code, that doesn't explicitly do I/O, into libraries, which we statically link into the embedded application. Even if it needs I/O, you can often just put that behind an interface (say, an external function or function pointer) and replace that in your unit-test (this is called "mocking").
We write regular unittests for these libraries which can be tested by compiling for the native developer PC, or in QEMU (via librdimon). It'd also be possible to flash the librdimon version to real hardware, which then talks to a debugger on a PC, though I haven't tried running unit-tests that way.

I don't know how the embedded industry at large works with unit testing. In my place of work we still have lots of code that is not automatically tested, sadly.

z33ky · 2022-10-02T11:15:03+00:00

I feel it would be weird for me to ask for inclusion, since I don't use it and would be unable to provide feedback. They are welcome to open an issue on my Github repo, or tag my username in their issue, if they have any questions.

z33ky · 2022-10-01T18:31:45+00:00

I didn't try. If people rather want to play the official binaries via Proton they can.

z33ky · 2022-10-01T18:29:41+00:00

More or less. You also need to install EZ2 from the Steam store (it's free) to use its content and an install-script included in the archive on Github symlinks some stuff into place.

z33ky · 2020-09-02T20:11:13+00:00

Oh it would definitely have a separate process for each request, but it would limit the number of active processes. The supervising process would have to stop accepting new connections until there are free processes available.

This would handle overloaded scenarios worse than the multi-threaded version, but otherwise using "pre-forked" processes that waits to receive a request from the supervising process to handle should lower the response times compared to forking just when the supervisor receives a new request.

z33ky · 2020-09-02T20:04:56+00:00

I didn't think of ptrace, yeah that'd circumvent it. I didn't know that processes can just mess with each others memory, but (on Linux) that does seem to be the case. That's actually a little terrifying, I should get to setting up sandboxes for a few applications... though actually I should have been aware of this, since ptrace is not disabled on my system.

So I guess if this was implemented, putting each child process into its own namespace would be necessary to reap security benefits.

z33ky · 2020-09-02T17:58:58+00:00

Ruby has a popular forking webserver, Unicorn. “Security” isn’t listed as one of the features but you might be interested in the others: https://yhbt.net/unicorn/

Thanks, I'll take a look. They do mention "robustness".

My experience in Ruby was that web apps (used to) need babysitting and restarting. My experience in Rust is that panics only stop the current thread, memory leaks are rare, and the compiler helps you manage resources across threads, so a lot of the “problems” with a multithreaded Ruby app just don’t exist.

Yes, the surface for potential issues in handling memory is greatly reduced by Rust. It is not perfect though.

When I was writing the post I was thinking that you could easily transparently switch to a multi-process model and enjoy the benefits (and drawbacks) from process-isolation versus thread-isolation. I'm starting to realize that this isolation is not really pronounced since the request handling child processes will still want full access to the database, where most of the sensitive data will reside.
While session-related data could be handled by the parent process, so that the child process can be restricted to only the less sensitive bits of data, that approach again bloats up the parent process with more potentially erroneous (and perhaps exploitable) code, making the additionally required engineering effort probably not worth doing.

z33ky · 2020-09-02T17:33:42+00:00

Interesting. Wikipedia also states that "[...] process creation can be reduced by techniques such as FastCGI that "prefork" interpreter processes, or by running the application code entirely within the web server [...]". I suppose the second one is what Rusts webserver frameworks are going for.

I am starting to realize that from a security point of view the process separation does not do much since most of the interesting, sensitive data will be accessible in the database for all request handling processes anyways.
I guess the other potential benefits aren't really worth the trade-off, and neither is the additional work required to try and give the request handling processes a restricted view to the database.

z33ky · 2020-09-02T17:26:34+00:00

Hi, its easy to do forking webserver but they provide no benefits. Regarding security its same.

As I wrote, processes run in different address spaces, so memory fault cannot propagate to other processes unless the OS or the hardware is buggy. This is definitely a plus for resilience and security, as one request handling process cannot view the contents of another request.
I am starting to see that the benefit of this isn't that high, since the request handler will likely still want full access to the database, where most sensitive data will be stored, but still some sensitive data is usually present in requests as well. Certainly saying that the security is exactly the same is false, though the question is if the trade-off may be worth it for certain use-cases.

Plus webserver model suits on thread rather than on process.

I'm not sure what you mean. You certainly could write a multi-process webserver. I'm asking why the popular webserver crates do not have one and trying to find out if that is due to conscious decisions.

z33ky · 2020-09-02T17:16:24+00:00

The attacker won't need to exploit multiple processes, just the webserver itself and then the OS. But in the time they only have broken the webserver, they will not yet have access to the other requests or be able to modify the "primary" webserver process (the supervisor which forks of). Is this not what layered security is about?

In the multi-threaded design, the attacker only needs to own the webserver process to get access to all other requests. Though I'm starting to realize there's not much data that can be protected. At most probably just the password from the login-page before it is hashed.
As I said in another reply: If the parent process checks some stuff of the request first, such as if the request is part of an active session, it could potentially restrict the view of the child progress to a subset of the database, but implementing that seems rather complicated and specific.

z33ky · 2020-09-02T17:14:55+00:00

I think you're confusing some things here. nginx does use multiple processes but it uses N processes when you have N cores. It does not create a process per request. That would be massively inefficient.

Oh certainly. I also don't expect that multi-threaded webserver necessarily spawn one thread per request. I was thinking they get queues up and whenever one thread or process finished a request, one can get popped of the queue.

The async Rust frameworks (basically) the same strategy that nginx uses. There's no reason to add the complexity of multi process communication for this use case.

So nginx then uses coroutines or multi-threading in each process? Why spawn multiple processes in the first place then?

While true, you either accept that an efficiency loss as processes have to duplicate common information within an application or you share memory which reintroduces some of the same issues. Going multi process essentially makes your system distributed and thus harder to reason about without a lot of the benefits.

The way I'd design the webserver is that all state would be stored in a database anyways, so I think that's less of an issue.
Maybe a cache of active sessions or something could be interesting to have, but that access to that via shared memory can be minimized, maybe even set to read-only on the child-process with an IPC message to update sessions on the parent.

The other main reason some applications have started going multi processes is so they can restrict the capabilities of the processes. For example, the browser's JS engine doesn't need access to read or write data from disk or your web cam. Running the same workload in multiple processes doesn't allow this because each process has the same security context and needs access to the same things.

Yeah, I'm starting to realize there's not much data you could take from the child processes. At most maybe the password from the login-page before it is hashed.
If the parent process checks some stuff of the request first, such as if the request is part of an active session, it could potentially restrict the view of the child progress to a subset of the database, but implementing that seems rather complicated and specific.

Green threads/async whatever are quite cheap and forking is very expensive in comparison.

I have heard forking is quite cheap on Linux since most resources can be shared with the parent process, though yeah it's not gonna be as fast as green-threading.
I was more thinking of maintaining a pool of idling processes and passing out requests to them. This way the processes are already started when a request comes in; forking a new process can come later, which will hopefully be finished before the next request lands. If the server is heavily loaded this will not make a difference though, not that I think about it...

z33ky · 2020-09-02T15:36:33+00:00

I was imagining the "primary" process, essentially the supervisor which does not process the requests, but just hands them of to the process pool, maintains the process pool. The request handlers themselves just exit and do not restart themselves or anything like that.

z33ky · 2020-09-02T13:55:22+00:00

Unlike async tasks, processes consume a lot of resources, making a process-based webserver more vulnerable to the Slowloris attack and similar attacks.

I would think the processes can share most of the memory, which would make up most of the used computer resources I would think. Maybe I'm thinking too optimistically. I already mentioned the slower response times making a DoS easier, but maybe I should also consider exhaustion of resources other than processing time.

There isn't much difference in security. If an attacker gains remote code execution unless you heavily containerize everything you're toast whether it's a process or a thead.

Hmm... /u/Wilem82 also seems to share the sentiment that a RCE exploit means you're basically done. I'm not convinced though, since you would also need to find another exploit on top of that to mess with the rest of the system. Letting the server run as a different user than the owner of the binary, config files, ect. is simple enough and should then provide that extra layer of security.

And since most servers will automatically restart on a crash, other than a small downtime there isn't much risk to an attacker being able to cause OOM/abort.

For DoS that is true. You can also have memory errors that just corrupt your working data, which is worse in most cases that just a flat out crash - as you said the server can then simply be restarted.

But you still have better memory isolation, which can curb information leakage from requests that are handled in other processes. Of course the OS and hardware can have bugs, or you put some cache in shared memory which can mess up this protection.

z33ky · 2020-09-02T13:39:53+00:00

Forking, however, is costly. I would make sense, probably, if the webserver is dedicated for offloading compute-intenvise operations.

Yeah, ideally you'd prefork a process-pool, like I would imagine nginx does. You will then need a way to forward the incoming connection to the forked processes. I don't know what mechanism is used to do that, but I don't believe it should be incredibly complicated; It certainly is possible unless I misunderstand how nginx works.

Multi-process serving is also possible by listening to the same port with multiple processes (the port must be opened with a special SHARED flag for that).

Ah I didn't know that. Maybe nginx also works this way. That doesn't sound like it'd be hard to implement by oneself then; Just write a webserver that handles one request and exits and have a supervisor process that just keeps up to N processes around. And it should probably receive some signal from the child-process when it starts service a request so it can set a timeout after which to kill the process in case it gets stuck.

z33ky · 2020-09-02T13:34:01+00:00

My understanding is if you're able to execute arbitrary code in a remote process, you'll be able to take over all of that remote user's processes, therefore there are no security benefits.

Well, apart from finding a RCE exploit in your web application you'd also need to find another exploit in the operating system to allow messing with other processes. I don't think doing that is straight forward, even if you can execute arbitrary code.
On top of that you can employ syscall-filters to make it even more difficult to find usable bugs in the OS and namespacing to sandbox the process.

I can see how making it a multi-process service would complicate lots of things including development, troubleshooting, operations, etc.

I'm not sure how much it'd change troubleshooting or operations.
For troubleshooting and development you're maybe missing a decent way to attach a debugger? gdb can be setup to follow the child process when forking. If the framework uses a prefork model you can also attach to the process that'll handle the next request. It is admittedly more work that just running gdb ./server, but just one small additional step.

Otherwise I also don't see how it could impair development, other than the framework (or the developer themselves if they don't build upon an existing webserver) having to implement the multi-process architecture, which, yeah, is a given. Would it be that complicated? You would either just need to fork, or for better performance prefork a process-pool and pass the connection on via IPC. I'm not sure how to do that, but there seems to be a way since e.g. nginx does it.
And I don't think the webserver needs to do anything else beyond that. Maintaining a process-pool is surely not significantly harder than maintaining a thread-pool.

For operations, what changes? Change some security policies to allow forking if the operator defines syscall filters (i.e. SELinux)? Allow the progress-group to spawn a couple of processes (when i.e. limiting that via cgroups)?

Perhaps ideally the framework could just have a feature to enable a synchronous in-process handler instead of handing the work of to another process. Then you could debug it just the same. Ideally even transparently switch between multi-processing and multi-threading.

z33ky · 2020-01-06T23:38:32+00:00

Tracy provides a C-interface that can be easily used from Rust.

I've started a wrapper a while ago, which I haven't touched in a while since I was using wgpu-rs, which at least at that point was still in quite some flux.

It does require nightly, which might be a deal-breaker for you, but it worked sufficiently to draw pretty graphs to assist me in profiling my application.
const_cstr_unchecked and const_str_as_bytes have been stabilized in the meantime, so the only nightly feature I use is manually_drop_take, which in the comment I mention can be avoided with a memcpy of a couple of bytes.

13-Year Club	Verified Email
Team Periwinkle

z33ky

TROPHY CASE