mirashii

If I’ve understood correctly, what your missing here is that the first core in SMM tells the second to join it in SMM, times out on the wait, does its thing and exits, but then the second core joins SMM after the first has exited, so now the first core is running outside SMM, second core in SMM, so first core can attack the second.

Just FYI, it’s “piqued my interest”

What’s the point? To save money paying a human to man a support email. That human would have also been hopelessly uninformed for all the same reasons.

The root cause seems to be known, unlike what this article implies. A bunch of other articles discuss the entropy issue, https://insider.btcpp.dev/p/when-randombytes-runs-but-doesnt for one I found quickly.

> give them a json specification, they're not always amazing at following it

Used correctly, this hasn't been true for a quite a while. Most inference engines have a form of grammar constrained decoding. See, for example: https://vllm.ai/blog/2025-01-14-struct-decode-intro

> The Fil-C runtime is tiny compared to TS and C#

Sure, this is a simple fact.

> So Fil-C is safer than those

This is not a simple fact that follows, and a good example of why you seem to be catching so much criticism for overly bold claims. One could state that a smaller runtime is easier to audit, and so the investment needed to reach similar levels of safety is lower. One might even argue that after similar levels of investment, that the probability that it's safer is higher. But jumping all the way from lower number of lines => safer is a simple fact is a huge leap.

I generally agree with all of this, but I'll add a few additional remarks. Because it's come up a bunch lately, I decided to do a bunch of code review/audit of the Fil-C codebase, and I'd say while it's got a lot of good bones, there's a long way to go to being a foundation I'd be ready to build on. I've reported a few UAF's upstream, and I've got a few PRs I'll add on, but if it only took me a day or two to find some of these big holes, I'm sure there's more lurking under the surface. I'd consider it to at this point be more of an engineering demo that this approach is feasible and tractable, but not a production ready language that I'd want to ship code in.

On the muddling the discourse, I'm not on twitter and don't engage there, so I don't have an opinion on that, but I did come across https://news.ycombinator.com/item?id=49044561 recently, and I just don't see how the author can make such bold claims while examples like the one Steve provided above are still in the language. Corrupting memory in Fil-C is still easy, type confusion is still easy, intra-object overflows are still easy. Fil-C prevents a range of classes of bugs from being exploitable, but it doesn't stop the bugs from happening.

I think the consensus is that this would be the wrong end to tackle the problem from. Your project should include ruff at the version it wants to use in its pyproject.toml. Bump the version when you're ready to spend the time on one project, but no need to coordinate across multiple projects. If you really want to do it, you can, but if there's one hold-out, you're not stuck behind forever because one project can't move yet.

I've spent some more time over the last day looking at Fil-C more closely, and come to the conclusion that this:

> The thing that makes races hard to debug in C or C++ is memory corruption; that doesn’t happen in Fil-C

is just blatantly false. It's almost as easy to corrupt memory in Fil-C as it is in C. Type confusion is still allowed. You can still do out of bounds buffer reads/writes as long as they fall within an allocation, so any intra-object stuff, as you might get in common packet or binary file parsing, is still about as unsafe as it was before.

The really silly thing is that Fil-C and Zig here have chosen a definition of memory safety that specifically excludes a bunch of overflow vulnerabilities and type confusion. At least it’s been specifically defined, but such a narrow definition makes the end result to me almost wholly uninteresting. UAF no longer turns into a RCE, but your average parsing packet code is still just as likely to be a buggy mess.

I’m having a hard time understanding how these two things can be true at once. Just because the capability exists that somewhere in my program a valid pointer to a piece of memory might exist (what I understand accessible to mean), doesn’t mean that a particular write to that memory location under a data race that tears a pointer is valid. The data race may make a pointer that would never algorithmically appear in the program in the absence of races, and thus make writes that invalidate invariants that should have been preserved. It seems to me this still provides a way to corrupt memory in a difficult to debug way just like C. Am I missing something?

I like "honor system" as a term. I've been looking for the right term to replace the irresponsible usage of guardrails with, and best I've had so far is the pinky promise protocol.

Clearly not. Good security is about defense in depth. The service that was exploited was meant to be an offline, frozen package cache, it shouldn't have been anywhere near a network boundary to even allow this through. A single exploit in one service should not have been able to bypass all network filtering, monitoring, and alerting.

There is some aspect of baking the rules into the model, that's what I refer to as RLHF above (which I use here as more a catch-all term for a variety of post-training activities), but there are also external to the model classifiers that may run on the prompt input or on proposed tool calls to limit the way in which the model is used.

> They didn't turn off the network protections

Right, but this is my point in saying I can't reach the same conclusion that they've invested a lot into these systems for production models. Either they had better network protections, and turned them off in their "sandboxed testing environment" (their words), or they don't have more comprehensive network protections at all and rely on this one, extremely thin layer even in production.

> I expect OpenAI would agree with you that "the lack of a real sandbox or airgap is nothing short of irresponsible on OpenAI's part". They have clearly invested a lot in those systems for their production models, but in this case they had deliberately turned a bunch of them off for a research project.

I'm not sure I can reach the same conclusion. There's no reason that stronger network protections would need to be turned off for a research model that's not supposed to have internet access. There's no reason that it they couldn't continue to run in whatever hypervisor or VM that any other production systems could use. The only thing that should be turned off for this type of work are the non-deterministic classifiers that they use for auto-approval mode in their harness, and I would wager that's the only one they did turn off.

> Given the absence of guardrails there was nothing to prevent the model from attempting to break out of that sandbox, break into Hugging Face, and read the answers from there instead.

I've said this many times before and I'll continue to shout it, but using the term "guardrails" to refer to anything that's either (a) in-context, or (b) a probabilistic classifier (including using other LLMs), is an irresponsible abuse of terminology that we as an industry need to put a stop to. Guardrails are the actual systems we build in place around these things that deterministically bound the permissions, not prompt engineering, not RLHF, not external LLM-based classifiers. I believe those types of "guardrails" are a result of a combination of fundamental laziness: they're faster to do than doing things correctly, and a result of too many folks involve being AGI-pilled, thinking we're just one more model away from this all being so smart that it just understands what they mean when they give an LLM some fuzzy language rules to follow.

There can and should have been additional real guardrails put in place here. Zero-day or not, breaking into what should have been an offline, frozen package cache that also does not have internet access should have been insufficient. Network level protections should have identified the traffic to the internet originating from this network as an anomaly long before there was time to exploit an outside company. These are not new and unknown problems, the lack of a real sandbox or airgap is nothing short of irresponsible on OpenAI's part, especially given how much they like beating the drum on how dangerous these technologies are. Shame on them, and honestly, shame on Simon in this article for accepting the broken terminology that they continue to rattle off and calling them out on their half-assed and demonstratively inadequate approach to security.

Add to that list respecting the TOS of the user's ISP so that the user does not get banned, and providing some sort of remuneration if illicit activity through the proxy causes problems for the primary user, and then _maybe_ you could call this all not shady as fuck.

There’s a number of comments and linked threads suggesting it is not, but easier to just link the biggest thread than try to track all the subthreads.

A Github issue with actual data instead of just someone reposting info: https://github.com/openai/codex/issues/28224

Previously discussed: https://news.ycombinator.com/item?id=48626930

A Github issue with actual data instead of just someone reposting info: https://github.com/openai/codex/issues/28224

Previously discussed: https://news.ycombinator.com/item?id=48626930

Yes. Flash cells in SSDs are rated for a particular number of write cycles.

This metaphor, while it seems intended to challenge the OP, kinda reinforces it. Many countries and cultures give some limited access to alcohol at a younger age, and the result is generally that they end up having fewer instances of problematic binge drinking when they come of age. A little bit of exposure instead of complete abstention helps people learn to have a healthier relationship than letting them hit 21 and dropping them into the deep end unrestricted.

This is and has been a common term in any systems programming concept for decades. You can, for example, search CVEs and easily find some from over 15 years ago: https://www.cve.org/CVERecord?id=CVE-2010-1119

It was even enumerated in the first pass of CWE as CWE-416 in 2006.

> what is most likely a simple mistake or process breakdown

I think this needs justification. My status quo is to believe that most times I have a problem when dealing with these large corporations that they've made any process for getting support or remediating what _should_ be a simple process breakdown is a labyrinth of steps to make it as difficult as possible to reach any sort of remedy to discourage you from even trying. People are raging because calmly asking for assistance doesn't work, the only way to pierce through is to make a scene big enough that it risks reputational damage to simply get the attention that every individual deserves.

> that constellation is already up there and if its fine right now

A lot of astronomers disagree.

The default sandboxing for Codex does not allow the agent to access .git

The math trades still happen regularly at cons, e.g. Origins had one just last week.

I guess I'm glad I snap bought, looks like I may have gotten the last one on Amazon for the 14" at least. I see a couple 16" options around at slightly higher than they were at retail but steal cheaper than Apple's new prices.

There are some Apple resellers that haven't quite caught up to the price increase yet. I just got a 14" M5 Max 128G, 2TB for $5100 off Amazon through Adorama, https://expercom.com/products/16-inch-macbook-pro-with-m5-pr... seems to have them in stock as well.