tptacek

It's its own OS.

It really is a great feeling; all my favorite HN threads (that I was involved in) are ones I kicked off with what I felt was a dumb question.

It is when the "AI slop" is literally the only source of time-sensitive information, as it is here.

Sorry, I'm neo-Cloud brained. You're right; AWS is the only hyperscaler I know of that uses Firecracker.

What do you mean "it replicates worldwide"? What replication are you referring to?

I agree with half of this argument but think you're taking it too far when you reject IQ testing as an epidemiological tool. It's not dispositive. It's statistically ill fitted as a ranking tool, for the reasons you stated, and the fact that it's not reliable across its whole range, and test-test reliability issues, &c. But like, "you can use it as an indicator for environmental causes of cognitive harm" is actually a valid argument, I think?

You've repeatedly claimed it, but the logic doesn't hold. KVM is a dependency for Firecracker, just like brotli is a dependency for Node. What matters isn't "who's according-to-Hoyle responsible", what matters is "are you exposed to it".

Not for nothing, but it would have been possible for Firecracker to disable the partial checksum feature this vulnerability exploits. If you wanted to push on the argument a bit, you could say that Firecracker ran virtio-net in an aggressive and possibly unsafe configuration. I wouldn't agree, but it's a colorable argument.

Two things.

First, you're the one who brought up this stupid article claiming that I'm singlehandedly responsible for the failure of DNSSEC. Not me. Next time, don't cite it!

Second, you have a funny definition of "thoroughly answered". People have written posts disagreeing with it. Their arguments are not persuasive. Clearly, for the last decade or so, my arguments have been carrying the day. You can't just write a rebuttal and declare the debate over!

DNSSEC proponents are weird about this stuff. Someone else took me to task for not point-by-point including their rebuttal article in my original post, like that's a reasonable demand to make.

You're giving away the game here by building an argument around national IQ statistics, because there is no such thing. There are serious surveys of IQ test results in places like the United States, with some statistical validity. There is no equivalent global country-by-country survey that would enable you to compare the United States to India or any other country. The reason people believe there are is because there are multiple fraudulent studies that claim to provide those numbers, and people cite them without reading the underlying papers and seeing what they did to generate those numbers.

No, you mean to say "if we define intelligence as the output of IQ testing", which clarifies that you're projecting from statistical surveys (with all sorts of potential confounders) rather than some directly queryable and innate attribute of people.

Probably because people take the idea and run it right off a cliff like Wil-E-Coyote, because very few commenters on message boards know what "heritability" actually means.

Wait, this is the opposite of reality. IQ is in fact a useful tool (in a battery of other tools) for helping diagnose cognitive deficits and learning disabilities. That's what it's good for: as a clinical tool. It's in fact terrible for ranking people.

Difference in IQ test scores between racial groups in the United States is established and replicated. Differences in innate intelligence are not. It's not hard to intuit the difference; you just ask yourself, "I wonder what else could have been different between racial groups in the United States at the time these surveys were conducted?".

This is a message board trope. In reality there are multiple fields of study, all of which feature active and frequent publication in major journals, that address this question. Also: intelligence is not racial.

I'm sure there will be! They've been extremely rare to date, because KVM is itself a relatively simple piece of code, but everything's up for grabs now.

The standard Firecracker setup uses a jailer that the Firecracker project provides. This generally isn't something you need to go out of your way to do.

Thanks! This makes sense. It also, of course, makes the jailer irrelevant; just find a non-jailed process to inject into.

Sure, sorry, I meant providers --- all the providers are using virtio-net.

The jailer doesn't give you debugging APIs to work with. Jailed, if your original exploit only gives you RCE in Firecracker itself, you still need another LPE vulnerability to break the sandbox.

If they have arbitrary code execution in the Linux kernel itself (which it feels like maybe they should?) then the jailer is a nonfactor. But the exploit they write up sure seems like it's just getting code execution in userland from Firecracker itself.

The jailer is just a seccomp sandbox. It's not a novel defense system. Sandboxes get broken all the time.

And yet here we are! Your own source says I'm the prime mover. You better get smarter about convincing me to like DNSSEC, because if you don't, your project is doomed!

If you're a provider, you absolutely do; it's part of the stack. It's like saying "Ruby" isn't a part of "Rails".

Both, maybe? I mean: whether or not they broke the jailer, we know the jailer is breakable; it wouldn't really even be newsworthy to have an LPE that breaks the Firecracker jailer.

Hey, I don't write AI blog posts. But I want to know how KVM escapes work, too.

I just don't think "can you run CIFS easily under it" has much to do with whether someone like Replit should use Docker, Firecracker, or gVisor.

I mean, it's good to want things, but I don't know what that gets you today. They're not going to give you the hand-crafted post you're asking for.

You can't insist your way through not learning about one of the most important vulnerabilities announced in the last 50 days.

Who cares? The overwhelming majority of cloud customers just want to run straightforward Node.js apps.

I read your whole post, which ended with "if users copy around fingerprints", which is a problem the built-in SSH PKI that large fleet operators already use solves. I don't think I misconstrued you.

You don't have to keep replying, but I'm going to point out that we have gotten no closer to finding a reason that anyone would even entertain the idea of SSHFP, a system that wires the already perfectly good SSH PKI subsystem into the state-controlled DNS PKI. Why would anybody ever do that?

No.