[dead]
First public macOS kernel memory corruption exploit on Apple M5
61–70 of 140 posts
Re: First public macOS kernel memory corruption exploit on Apple M5
#62I’m surprised Apple is still not dogfooding their allegedly safe language Swift. Or was the whole exercise of Swift 6 mostly marketing
Swift is definitely being used at apple. Most recently added as a CSS parser in safari and running embedded in some of the secure enclave parts. I know there was talk from as far back as strangeloop to get it in the kernel but I'm not sure how far that has gone. That being said they've been huge proponents of fbounds check in clang which can achieve a small portion (but important!) of what memory safe languages can do. I'd also like to see more swift or alternative adoptions I think they have potential and more competition in the safe language space is always welcome.
Re: First public macOS kernel memory corruption exploit on Apple M5
#63I’m surprised Apple is still not dogfooding their allegedly safe language Swift. Or was the whole exercise of Swift 6 mostly marketing
You might be interested in the Strict Memory Safety option
https://docs.swift.org/compiler/documentation/diagnostics/st...
Re: First public macOS kernel memory corruption exploit on Apple M5
#64Re: First public macOS kernel memory corruption exploit on Apple M5
#65Earlier quoted context omitted.
you're assuming that blue teams and engineers are sitting around twiddling their thumbs
Not at all. I’m considering that the amount of vulnerable software in the wild is very, very large, with most organizations not managing their systems properly. Imagine all the small to medium size companies that do not have budgets for a dedicated, talented security team. And all the software that will never be patched. We are at the beginning of the exponential
> I’m considering that the amount of vulnerable software in the wild is very, very large
I'd imagine this set is very similar to just "the set of software on the world". Even before the AI stuff, it was a pretty good bet at any given software had some vulnerability; it was just a question of how easy to was to find it.
Re: First public macOS kernel memory corruption exploit on Apple M5
#66I’m surprised Apple is still not dogfooding their allegedly safe language Swift. Or was the whole exercise of Swift 6 mostly marketing
They certainly are, one of the reasons behind Embedded Swift is to replace iBoot firmware currently written in a C dialect similar in ideas to Fil-C, with something better.
However it is no different from the Linux kernel, just because Rust is now allowed, the world hasn't been rewriten, and no sane person is going to do a Claude rewrite of the kernel.
Re: First public macOS kernel memory corruption exploit on Apple M5
#67Earlier quoted context omitted.
> The world is so not ready for the impact of LLMs on security issues. I agree, but it's the people I'm worried about. I'm hearing anecdotes from all over about devs pushing LLM-generated code changes into production without retaining any knowledge of what it is they're pushing. The changes compound, their understanding of the codebase diminishes, and so the actions become risker. What's worse is a lot of this behavi…
The gamble is that you can cruise on the senior engineer’s diminishing understanding for a few years until models become good enough that you don’t need any humans in the loop and you can fire all those expensive seniors.
The tragedy is having a bunch of those senior engineers writing blog posts and what not of how productive they are, without realising that it means business now needs less of them.
Re: First public macOS kernel memory corruption exploit on Apple M5
#68Earlier quoted context omitted.
is this exciting? juniors have been writing code forever that is imperfect and not memorized by the people reviewing isnt the important thing the mechanisms for maintaining the code?
The difference is twofold. First, junior devs who ask for code reviews on massive, 2000+ line diffs get coached, and eventually fired if they persist at it. And second, even the most prolific junior engineer would take years to write what Claude is capable of generating in an afternoon. When Sundar Pichai announces that 75% of all new code at Google is AI-generated, their stock price goes up. If he were to announce t…
The second scenario is exactly what happens in offshoring projects.
Seniors are only part of the picture as team leads, or when it escalates after big screwups.
Re: First public macOS kernel memory corruption exploit on Apple M5
#69Earlier quoted context omitted.
is this exciting? juniors have been writing code forever that is imperfect and not memorized by the people reviewing isnt the important thing the mechanisms for maintaining the code?
The difference is twofold. First, junior devs who ask for code reviews on massive, 2000+ line diffs get coached, and eventually fired if they persist at it. And second, even the most prolific junior engineer would take years to write what Claude is capable of generating in an afternoon. When Sundar Pichai announces that 75% of all new code at Google is AI-generated, their stock price goes up. If he were to announce t…
The second scenario is exactly what happens in offshoring projects.
Seniors are only part of the picture as team lead, or when it escalates after big screwups.
Re: First public macOS kernel memory corruption exploit on Apple M5
#70Earlier quoted context omitted.
I can only imagine that 1. it’s to performance sensitive Or 2. The os is so darn large it’s hard to recompile everything
I worked at Apple for a long time. The OS gets fully recompiled regularly. A simultaneous total world build is relatively rare (is that needed here?), but it does happen. Sometimes new compiler versions or features need this.
I dunno if that's sensitive information, but how long did a build usually take?