HN user

strstr

1,079 karma
Posts5
Comments264
View on HN
Remote Attestation 14 days ago

(I’ll bite and try to steelman) How does a typical user verify that they are running the intended secure software?

You can definitely do this without sorting.

QuickSelect is average case n, and is, roughly, quick sort where you throw away one of the sides each time and recurse on the other. This has a fat tail for cases where you pick a bad pivot (similar to quicksort), but you can median-of-medians your way out of that problem if someone cares. (Median of medians being where you subdivide the array into, say, 5 arrays, recursively compute the median on those, and pick the middle median as your pivot, which guarantees linear progress per iteration)

Split locks are weird. It’s never been obvious to me why you’d want to do them unless you are on a small core count system. When split lock detection rolled out for linux, it massacred perf for some games (which were probably min-maxing single core perf and didn’t care about noisy neighbor effects).

Frankly, I’m surprised split lock detection is enabled anywhere outside of multi-tenant clouds.

The AI Vampire 5 months ago

Popular blogger from roughly a decade ago. His rants were frequently cited early in my career. I think he’s fallen off in popularity substantially since.

This is more of a typing game than anything else. It rejected “blackcapped chickadee” (wanted black-capped chickadee). Frankly that felt a bit tedious on a phone. Had to scrub through to correct and lost.

Legitimately, they are often too hard. Balancing the problems is quite challenging.

On top of that, the solutions often make the problems seem much intimidating than they are (not that they are easy). Most solutions involve a lot of “happenstance”, where someone tried something and it got an outcome that was useful, which they build on top of. This makes the solutions look crazy complicated (“how would i have ever thought of this!?”), when in reality they are Rube Goldberg machines built out of duct tape and baling wire.

I’ve only solved a few Google CTF problems, and one of them was the one I wrote, lol. That was nearly a decade ago though.

In practice, it’s essentially infeasible to make a non-detectable virtualization stack. Timing is really really hard to match (as is everything else). You can edit the binary that’s doing the detection, but this is time consuming. Every new feature they push costs you time and will poison your hardware id.

You can go further by, say, requiring fTPMs that are on the SoC (super common these days for most recent consumer CPUs). If you can’t boot into linux without the PCRs reflecting your virtualization stack being in the boot chain, you’re cheat is quite detectable.

Allegedly some of the anticheats are configuring the IOMMU through Windows APIs (vanguard, faceit, and a smattering of chinese anticheats). It’s hard to find good public information though. They do some mix of blocking access and deliberately leaving some pages as bait (and monitoring iommu d-bits/faults)

Cheating will slowly look more and more like trying to hack your own machine.

Secure Boot+TPM combined with decent firmware will make cheating a lot harder. If the firmware ensures random devices don’t get BME set before the IOMMU is properly, attestably, configured, you are basically now stuck looking for bugs in the TPM and UEFI if you want to shove yourself beneath the OS unnoticed. These are full of bugs, so that will work for a while, until it doesn’t.

Popping windows will probably work for some time, but HVCI will make this a pain once ubiquitously required.

And you have to do all of this while also not being detected for aberrant behavior. Eventually, the analog hole might end up being easier, lol.

With the default key hierarchies, the benefit is more limited. It raises the bar. Implementing known vulnerabilities takes work. And not ever configuration is vulnerable to every issue. And, for a lot of the vulns, the OS vendor shoves things in the dbx to mitigate.

With custom hierarchies, it's a bit more compelling. But it's a lot of work to maintain.

Tried cheating with Gemini 2.5 pro, and I became even more suspicious to the AIs than the stuff I cooked up by hand.

Most of my actual success relied on mentioning a desire to train an even larger model.

The most interesting toy economy I’ve seen has been d2jsp and its “forum gold”. Forum gold is primarily used as a fiat currency for diablo 2 trading. It’s a janky digital currency on a janky forum from like 20ish years ago, that’s still alive today. You can technically buy the currency from the forum, but in practice few do that. Most people just trade items to bootstrap.

Having futzed with bartering in diablo (and non-fiat trading denominated in items of stable value), I quickly came to appreciate fiat currency. Being able to combine two “half trades” into an equivalent barter exchange is vastly easier.

At one point I was able to trade some of the forum gold I accumulated from diablo 2 for a “perfect IV foreign Ditto” for shiny pokemon breeding.

Had the same experience. Took the janky decompilation from ghidra, and it was able to name parameters and functions. Even figured out the game based on a single name in a string. Based in my read of the labeled decompilation, it seemed largely correct. And definitely a lot faster than me.

Even if I weren’t to rely on it 100% it was definitely a great draft pass over the functions.

Gemini 2.5 1 year ago

Ooof, it failed my "Wheel of Potential" bug finding question, and got aggressive about asserting it was correct.

Gemini 2.5 1 year ago

It's a lot better at my standard benchmark "Magic: The Gathering" rules puzzles. Gets the answers right (both the outcome and rationale).

You are probably saying this as a troll, but I’ll bite. I mean, sure Rust would have helped.

Technically, the borrow checker and bounds checks wouldn’t have done it here (I’m aware I’m being obtuse by not just linking the bug).

Having cleaner types and abstractions would almost certainly have solved the problem though. Normal C++ would have worked as well as Rust.

This isn't wrong per se, but rather, it lacks concrete recommendations for what should be done differently.

I would love to see Linux thoroughly and meaningfully tested. For some parts it's just... hard. (If anyone wants to get their start writing kernel code, have a crack at writing some self-tests for a component that looks complicated. The relevant maintainer will probably be excited to see literally anyone writing tests.)

For this particular bug, the cheapest spot to catch the issue would have been code review. In a normal code base, the next cheapest would have been unit testing, though, in this situation, that may not have caught it given that the underlying bug required someone to break the contract of a function (one part of Linux broke the contract of another. Why did it not BUG_ON for that...).

Eliminating the class of issue required fairly invasive forms of introspection on VMs running a custom module. Sure, we did that... eventually.

Finding it originally required stumbling on a distro of Linux that accidentally manifested the corruption visibly (about once per 50ish 30 minute integration test runs, which is pretty frequently in the scheme of corruption bugs).

Being an upstream maintainer is incredibly under-appreciated. It’s an unfathomably hard, and somewhat thankless, job (at least if you do it well). A friend of mine was in a cab with Ted Ts’o at a conference and he was reviewing patches on his phone to keep up with the workload (or maybe he was bored who knows).

Despite incredible effort from maintainers, getting necessary changes into Linux can take forever. In the subsystem I depend on (and occasionally contribute to directly) it’s kinda assumed it will take at least a year (probably two) for any substantial project to get merged. This continuously disappoints PMs and Leadership. A lot of people, understandably, chafe against this lack of agility.

OTOH, I’ve been on the other side of kernel bugs. Most recently, a memory arithmetic bug was causing corruption, and took my team at least an engineer year to track down. This makes me quite sympathetic to maintainers demands for quality.

I’ve also been on the other side of the calibration discussions where Open Source work goes under appreciated. The irony never stops (“They won’t merge our patches!” “Are you having your engineers review theirs?”). That and the raw pipeline issues for maintainers (it takes a lot of experience to be a maintainer, which implies spending a lot of a bright engineer’s time on reviewing and contributing upstream to things unrelated to immediate priorities).