charleslmunger

Even if that's the case, it's not "undefined" in the sense that it doesn't permit "now your program is the attacker's program".

Is a pretty successful open source NVR that used corals when it launched (and many people still use them with it)

My experience with the process as a first time submitter has been pretty pleasant, all things considered.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3899.pdf

Many fast allocators do not store the size next to the allocation, and may not store the requested size at all. This has the advantage that freeing a large allocation does not fault in cold pages with a write, as well as reducing allocator memory overhead.

Fil-C is amazing and a prime example that undefined behavior means implementor freedom, and the implementor can choose to always trap on null pointer use. Sometimes the implementor freedom doesn't buy you much; for example why should it be UB to do

    (const char*)NULL + 1

>OpenAI also required all Research CaaS workloads to use a micro VM sandbox

So yeah, they were not using it before and they should have been, and they're doing it they way they should have, now.

>exploited insufficient DNS filtering in its sandbox

If your goal is to use dns filtering to prevent your models from reaching the open Internet then you are not really serious about security. People have been tunnelling DNS to get internet access on captive portal wifi since 1998. There's not a lot of details in the blog post but I suspect this was also foreseeable.

>It's also hardly outrageous that they ran training and/or benchmarks with only network-isolated VMs with access to a package repository.

At least in the black hat talk they gave, they said that they noticed that the agents had compromised the package repo, and they remediated it, patched the vulnerability the agents had used, then continued. But given that it was compromised again and they didn't detect it the second time, clearly they did not add monitoring or hardening or comprehensively audit it for further vulnerabilities. My point is that even if there had not been a widely known incident like this yet, that only could excuse the first artifactory compromise, not the second. They had notice because it had already happened to them and they detected it.

As for breaking out of the VM, my point is that the agent should have had to. The comment

>they were running in network-isolated VMs with no access to the internet.

Was not accurate, the network isolation was not done at the VM level.

They were not in network isolated VMs, from my understanding they used containers sharing a kernel, so a Linux kernel local privilege escalation across the whole syscall surface (there are zillions of these) was sufficient to break out. Breaking xen or firecracker or something would have been much harder, which is why cloud providers running untrusted workloads use them and similar tools. No system is impenetrable but it's not like they were following best practices here.

On a sufficiently anemic CPU doing enough fast allocation you can get measurable improvements from that kind of thing, but for a superscalar CPU and a general purpose allocator I agree you'd be hard pressed.

First, you can get deadlocks as interrupt now calls arbitrary code to close channels. Second the interruptee thread cannot recover from an interrupt, if it chooses to to. Lastly it means that a server that shares a file descriptor with multiple threads breaks unrelated operations on interruption.

Don't know anything about the second one.

Firecracker avoids sharing the whole kernel, and gvisor drastically reduces the attack surface of the kernel. Breaking through both layers would have been much more challenging and a demonstration of the model's capabilities rather than the sandbox's weakness.

Artifactory is self evidently not a security barrier, and as an exposed network service it should have been audited and after the first issues were found, rejected as a candidate. There's never just one security vulnerability.

This was actually possible in 2011 or so, and a friend and I implemented it for a school project. How well the ux works depends on whether you want to use a key exchange protocol for the in person communication.

As far as I know there is no reasonable compiler that wasn't specifically trying to add some kind of sanitizer that would emit anything other than plain memory reads, but it would be nice to not have to worry. But sanitizers are handy! I can imagine some sanitizer implementation forgoing extra internal synchronization that would only be needed in the case of program UB anyway.

https://github.com/protocolbuffers/protobuf/commit/9f29f02a3...

1. Amd HDMI 2.1 fiasco and adapter workarounds -> debugged the adapter compared to the displayport spec pdf, emailed the company, got a firmware update, patched my kernel. Fixed! This one is going away for good with FRL support upstream soon.

2. Game stops responding to controller input after playing for a bit. Debugged, turns out the service for doing something fancy with shaders has shared fate with the steam input process. It launches a zillion threads and OOMs from virtual memory exhaustion which takes out steam input; fixed by adding a wrapper script for steam that reduces thread stack sizes to the windows default size.

3. Xbox elite series 2 controller back buttons not supported in 2.4ghz wireless mode; reverse engineered the USB packets, contributed support to out of tree xone driver.

4. Flydigi controller software not supported on Linux; find random GitHub project that reversed their hidraw protocol. It's got bugs, so fix them and use it.

5. Terrible banding in Silksong. Set up gamescope to apply dithering; this breaks steam input, figure out all sorts of incantations with LD_PRELOAD

But all of these are very much off the beaten path problems, lots of people have fun with normal controllers, no VRR, etc. My steam deck has been just perfect with zero effort, and I assume that's because I'm not treating the system configuration like a puzzle game.

https://daniel.haxx.se/blog/2016/10/14/a-single-byte-write-o...

And if you get code execution, then you by definition have "anything".

A standard way to eliminate those is to invoke undefined behavior if some condition is not met;

    if (a == NULL) {
      __builtin_unreachable();
    }