HN user

fay59

259 karma
Posts0
Comments100
View on HN
No posts found.

5 years seems like a low for Apple device longevity. I think that there’s an enormous difference between today’s Macs and Macs from 5 years ago and maybe the leap is accelerate deprecation, but there was a long period of stagnating macOS requirements. Hope we return to that for Apple Silicon Macs.

We could stop right here but this suffers from overflow limitations if translated into C.

FWIW, the final version also suffers from integer overflow limitations. If the difference between an and INT_MIN/INT_MAX (depending on whether you floor or ceil) is <= b/2, you will have integer overflow.

In context, it sounds like they relied on simulations that don’t use exact numbers. I’m guessing that they saw an IEEE-754 floating-point infinity and then had to determine whether they got it because the accurate result was infinity or if the infinity they saw was the result of floating-point calculation artifacts.

The “battle of preparedness” for grandmasters looks miserable. My experience being bad at chess is pretty cool, though.

If anyone’s looking to pick up chess, it’s a pretty good time to do it even if the people making a living out if it aren’t enjoying it anymore. It used to be that computers would only crush you without helping, but now they’re able to point at your mistakes and show you where the game shifted from one player to the other.

No, logic bug consequences are fundamentally different from memory corruption bugs. A bug with an access check for one resource in the kernel means you get access to that specific resource. A missing bounds check in the kernel—anywhere in the kernel—means you get arbitrary code execution. Sure, _sometimes_ you can escalate from one resource to another with an access check issue, but that’s a _sometimes_. One memory corruption bug _anywhere_ defeats the protection of _all resources, all the time_. Not only that, but memory corruption bugs have well-understood exploit recipes that attackers can make once and reuse any time they find a new bug to save work, whereas an attacker has to write a new distinct exploit for most logic bugs.

There is no equivalence to make. Memory corruption bugs are unambiguously, unequivocally better exploitation primitives than logic bugs.

No one is claiming that memory-safe languages solve logic problems. The claim is that most memory corruption bugs are conveniently exploitable and any exploit can reach for anything in the address space, and logic bugs often can’t. You could as well say that you’d rather promote chess pawns to knights instead of queens. Like, that makes sense sometimes, but it’s a bad default.

What the missing access check protected was a stream of information that could defeat ASLR. If Zircon was written in a memory-safe language, that would have been the end of the issue. Logic bugs and missing access checks are still possible, but defeating them has fairly well definable consequences. Since Zircon isn’t written in a memory-safe language, the author was able to use that to fully compromise the kernel instead. I don’t mean that you can’t write bugs in memory-safe languages, but in the end the attacker still has to play by your rules. With a memory safety bug, attackers play by no one’s rules.

That’s not really a “but” to the comment, which was that you need to find one bug and it’s game over. We’ve known for a long time that best practices aren’t enough to prevent memory corruption in large enough C++ code bases, so it’s likely a motivated attacker would eventually find something.

The intent of the post isn’t to claim that any Fuschia device currently sold is vulnerable. Unless Fuschia never graduates to running third-party code, that seemed like the right assessment to me.

Big fan of BBEdit, didn’t realize it’s just barely younger than me. I started using it probably about 20 years ago.

These days I use it mostly for one-offs and as a scratch pad. It’s doing a very good job at that.

MDN Plus 4 years ago

Criticism is not always respectful and it stings more often than not but it’s important to long-term success. What would help the open web even more would be to address issues instead of asking that no one brings up. (You’re also very much allowed to be tired of reading it over and over without it being invalid.)

It’s completely fair game to criticize the overhead costs of charities: it’s one of the most common things to criticize about charities, in fact.

MDN Plus 4 years ago

The difference with other services is that what people want when they subscribe to Spotify is access to music. What (at least some) people want when they subscribe to MDN Plus is ensure that Firefox and other open Web projects stay relevant. If people paid for Spotify merely so that Spotify stayed relevant, they would probably care in similar measure how Spotify spends its money.