For modern systems, stack buffer overflow bugs haven't been great to exploit for a while. You need at least a stack cookie leak and on Apple Silicon the return addresses are MACed so overwriting them is a fools errand (2^-16 chance of success).
Most exploitable memory corruption bugs are heap buffer overflows.
I do vulnerability research. Those things would do the exact opposite of what you're aiming for. They'd be received with glee by mercenary spyware companies, _especially_ being able to load things into higher levels of privilege.
that wouldn't be a problem, apple signs extensions. In windows land for example, there are ELAM drivers for security software, they don't just hand them out, you basically have to convince people at Microsoft you're one of the good guys, in person.
It means more surface (both from extensions themselves and the loader code), relaxation of things like KTRR/CTRR (you now need to add executable EL1 pages at runtime), plus the potential for signing keys to leak (Finding enterprise signing keys even for iOS is fairly easy).
Yeah, loldrivers are a thing because any signed driver can load, vuln drivers with ELAM .. I don't know of any, I believe they're quite rare.
You have a good point with attack surface, but apple has a pretty robust system already for ensuring boot and lock security that doesn't rely on EL0/El1 security. I'm sure you know more than me about higher EL's like EL3 and secure world code that can take care of all that. I'm pretty sure they don't have to issue new signing keys either, matter of fact, why let even 3rd parties do this, apple themselves could expose a memory and file system dumping api without involving third parties. That way, they could sanitize away anything they consider sensitive as well. They can also require that the commands be issued over a physical/authorized usb connection.
Point is, there are very legitimate are critical cases where memory and file system forensics could be critical. From what little chatter I've heard, forensic software today is resorting to exploitation of the devices and those exploits tend to be abused for other reasons too.
Do you know of any reports where macos system extensions being abused this way? I've heard about windows drivers, but my impression was apple is doing this well enough to be a non-issue mostly?
That's a good one. To be clear, I'm not saying vulnerabilities don't or can't exist in system-extensions. I'm just saying that apple can publish and/or sign iphone extensions for a very limited use case like this, or publish an api/system service to do the same thing, if the concern is 3rd parties. The use case here is reading some memory and exposing that to authorized applications. I concede on the system extension part, but apple can still expose the capability without one.
You're confusing your opinion of the company with the perception by the general public. Apple's definitely not perceived as 'an office appliance company' by your average person. It's considered a high-end luxury brand by many[1].
It'd run on a 5090 with 32GB of VRAM at fp8 quantization which is generally a very acceptable size/quality trade-off. (I run GLM-4.5-Air at 3b quantization!) The transformer architecture also lends itself quite well to having different layers of the model running in different places, so you can 'shard' the model across different compute nodes.
From what I've been reading the inference workload tends to ebb and flow throughout the day with much lower loads overnight than at for example 10AM PT/1PM ET. I understand companies fill that gap with training (because an idle GPU costs the most).
So for data centers, training is just as important as inference.
> So for data centers, training is just as important as inference.
Sure, and I’m not saying buying Nvidia is a bad bet. It’s the most flexible and mature hardware out there, and the huge installed base also means you know future innovations will align with this hardware. But it’s not primarily a CUDA thing or even a software thing. The Nvidia moat is much broader than just CUDA.
If an attacker somehow gains out-of-bounds write capability for a tagged memory region (via a pointer that points to that region, I assume), they could potentially write into a non-tagged memory region. Since the destination region is untagged, there would be no tag check against the pointer’s tag, effectively bypassing EMTE.
> I believe they mean the source region's tag, rather than the destination.
But in the previous case, the pointer the attacker uses should already carry the source region’s tag, so it’s still unclear if this is what they meant.
I’m not sure which attack scenario they had in mind when they said this. It would help if they provided a concrete attack example.
I have some inside knowledge here. KPP was released around the time KTRR on A11 was implemented to have some small amount of parity on <A11 SoCs. I vaguely remember the edict came down from high that such a parity should exist, and it was implemented in the best way they could within a certain time constraint. They never did that again.
Most exploitable memory corruption bugs are heap buffer overflows.
reply