charleslmunger

I stand corrected! I had assumed that Fil-C actually removed poison and unreachable states in the IR but thinking about it more that seems very challenging to do comprehensively.

This is sort of true, except that behavior can be undefined in the standard but defined in your implementation. One of the best examples is -fwrapv, which makes signed integer overflow not UB. And Fil-C has no undefined behavior that I'm aware of. But most implementations target the standard and "define" what the standard doesn't to be "whatever I feel like, in service of implementation simplicity and performance". What matters is what your implementation guarantees, which should be a superset of what the standard does.

If you meant standards committee replies, this proposal did pass an along-the-lines vote and is now in wording committee.

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

Sure. But consider what would happen if you had an array, and you looked up the nth element. If that base address is a null pointer and the index is greater than the size of your zero page reservation, it'll get some other address which is holding stuff. There's ways to deal with that too, of course, but not for free and it carries implications for other things. In Java this is avoided because arrays carry their length at the beginning, and you check that first for bounds, so if the array pointer was null you'd fault a small number of bytes past 0 and it still works.

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

Dereferencing null is and should be UB but why is just calculating a pointer problematic? I just did some research and some old architectures would actually trap on creating an invalid address. So if we want C to support those machines, the standard can't define the behavior to do something other than what the hardware does.

My understanding was that they were running on VMs, and there was at least one container inside the VM. So by breaking out of the container they compromised the VM, but they did not break out of the VM itself. The network isolation was enforced at the container level, so they didn't need to break out of the VM and compromise the hypervisor to move laterally. The technical report says:

>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.

The parent comment said

>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 saw the package repo get hacked once, then did not isolate it further, did not audit it for other issues (using their own models!), did not monitor it after, and baked that behavior into the weights via RL.

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.

I think that specific issue was a huge mistake, because it means the interruption, which was already messy, is now unusable.

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.

It needs a comment for sure. I always write a little helper utility to manage that when I need it.

The first is, annoyingly, a relatively common problem and solution when dealing with GC lifetimes in tests. Few interpreters/JITs want to generate extra instructions to null out stack slots or pre clobber registers to ensure something becomes collectible at a specific point. Eager nulling of a variable often gets removed by dead store elimination or even just from being a disconnected SSA node. I've written extra nested scopes or wrappers in Java to deal with this in tests.

Don't know anything about the second one.