Apple CPUs: SLAP and FLOP  - Page 1
Forum section: electronics / general

author: madires
author_rank: Super Contributor
timestamp: January 29, 2025, 11:51:42 am
content: https://predictors.fail/- SLAP: Data Speculation Attacks via Load Address Predictionon Apple Silicon- FLOP: Breaking the Apple M3 CPU via False Load Output PredictionsSLAP was reported to Apple in May 2024, and FLOP in September 2024. No patches yet.Media:- New Apple CPU side-channel attacks steal data from browsers (https://www.bleepingcomputer.com/news/security/new-apple-cpu-side-channel-attack-steals-data-from-browsers/)

author: jpanhalt
author_rank: Super Contributor
timestamp: January 30, 2025, 02:58:43 am
content: Does Apple in its documentation for M2 and M3 CPUs give credit to the copyright holders for the Great Gatsby or Harry Potter Sorcerer's Stone, respectively?If not, I wonder whether those copyright holders are aware of those vulnerabilities?

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 30, 2025, 08:54:31 am
content: I'm gettingquiteannoyed at speculative execution. The benefits are obvious, but apparently the security implications are too hard for even the brightest human minds toimplementdesign it correctly.

author: magic
author_rank: Super Contributor
timestamp: January 30, 2025, 10:05:20 am
content: To "design it correctly" would be to reset all state (caches, TLB, maybe predictors?) created by speculation when the speculation is discarded. So for the usual side channel which is L1, you would overprovision it enough that speculative loads don't cause evictions and tag those loads with the instruction which caused them and evict them when the instruction is aborted. Obvious performance and money vs security tradeoff. Gets even crazier for higher level caches although IDK if they are (or could be) used for Spectre attacks due to interference from other CPUs.The alternative is what we witness, which is a cat and mouse game where people come up with practical attacks against particular real world software and changes are made (usually to the SW, not HW) which make them harder, until another trick is found. Any HW feature which enables speculative executions will sooner or later be discovered by somebody and exploited, particularly if it's undocumented and software doesn't attempt to mitigate it.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 30, 2025, 10:22:22 am
content: Quote from: magic on January 30, 2025, 10:05:20 amNo, that is the brute force approach, the simple solution to a complex problem.One could also track all state changes due to speculation, and only reset/ignore the ones due to discarded speculation. Yes, it would mean an extra bit/two/three (depending on possible number of simultaneous speculations) in various items like cache slots, and would grow both the complexity and the amount of silicon needed to implement the caches and such.

author: DiTBho
author_rank: Super Contributor
timestamp: January 30, 2025, 01:20:18 pm
content: modern plague

author: BradC
author_rank: Super Contributor
timestamp: January 30, 2025, 01:38:28 pm
content: I think a large part of the problem is this is a relatively new architectural issue. It's going to take a proper processor generation or two for the underlying issues to be addressed and in the mean time it's all minor microcode or software mitigations.Quote from: Nominal Animal on January 30, 2025, 10:22:22 amIt's going to take some time (as in architectural generations) to build this into the underlying architecture rather than trying to patch holes.

author: coppice
author_rank: Super Contributor
timestamp: January 30, 2025, 02:01:05 pm
content: Quote from: Nominal Animal on January 30, 2025, 10:22:22 amSecurity is like ogres. It has layers. Deal with one layer, and someone finds the next. Can we bypass this, and get to total security? Probably not. I strongly suspect total security is a mythical concept. That said, some of the problems that crop up appear to be due to designers with constipation. They couldn't give something or other.

author: DiTBho
author_rank: Super Contributor
timestamp: January 30, 2025, 04:05:57 pm
content: Quote from: Nominal Animal on January 30, 2025, 10:22:22 amPerhaps, we should insert (around the CPU cores) circuits that shuffle bits without doing anything with thema bit like TwoFish rings dowith the only purpose of increasing the entropy of the systemdunno, speculative exectution and cache are always problematic, from many points of view

author: magic
author_rank: Super Contributor
timestamp: January 30, 2025, 04:20:33 pm
content: Quote from: Nominal Animal on January 30, 2025, 10:22:22 amYou just repeated what I wrote after stating that you disagree.Quote from: BradC on January 30, 2025, 01:38:28 pmMicrocode only works if the vendor left options to disable the problematic feature.We shall see how new players in this market fare

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 30, 2025, 10:44:48 pm
content: Yes, I don't know if it's really possible to implement truly secure speculative execution while retaining the performance gain. I personally lean toward getting rid of that altogether and finding performance increase with other techniques.I don't know if it's possible to design anything that is 100% secure anyway, and even if its 99.9999999% secure, someone will always find the flaw and exploit it, even if it's "costly" to do so, as long as the potential benefits of finding exploits are big.

author: DiTBho
author_rank: Super Contributor
timestamp: January 30, 2025, 11:52:46 pm
content: Quote from: SiliconWizard on January 30, 2025, 10:44:48 pm"the only secure server is a powered off one, buried under 10 meters of concrete"it was said at a CCC event, wearing the OpenBSD armored fish t-shirt

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 31, 2025, 07:26:10 am
content: Quote from: magic on January 30, 2025, 04:20:33 pmI misinterpreted what you wrote, yes. (It's as if I didn't parse the "created by .." at the end at all.) Apologies!It seems to me that speculative execution trades complexity and extra computation in order to reduce latencies. I'm not smart enough to have seen the issues in speculative execution beforehand; they came as a surprise to me. But, it increasingly looks like it is not the correct class of solutions for the problem of latencies at the machine code or microcode level.It would be interesting to see what, if anything, the RISC-V developers discussed wrt. need for speculative execution to squeeze maximum performance out of a processor core. Seems to me they are the least encumbered with backwards compatibility requirements, least stuck in traditional implementation paths (outside of highly parallel specialist cores, like GPUs, NPUs, xCore/XMOS, and tile processors in general).

author: magic
author_rank: Super Contributor
timestamp: January 31, 2025, 08:59:35 am
content: I think it came as surprise to almost everyone, but now that the cat is out of the bag new attacks are delivered on regular scheduleNot sure what you could replace speculation with. Obviously SMT or simply more smaller cores, but that doesn't help single threaded code and there is plenty of demand for that.Also not sure how power efficiency works out, because on one hand you sometimes execute pointless instructions, but on another an idle core waiting for something to finish wastes static power too. Maybe the winner is SMT, but it's still MT.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 31, 2025, 10:14:48 am
content: Quote from: magic on January 31, 2025, 08:59:35 amI often mention how the way almost all HPC simulation programs do computation and communication in sequence instead of in parallel irks me to no end. It's done that way just because the humans writing the programs cannot or will not work it out. I have investigated this a lot, and itcanbe done, even for Monte Carlo simulations (although I have only numerical proof of detailed balance being maintained).At the core, it is all about just being aware of a conditional situation well in advance, resolving the condition, and having sufficient other work afterwards before the condition needs to be acted upon.In many ways, it is similar to prefetching, except prefetching fits well in imperative programming, and many have problemsgrokkingthis kind of asynchronous approach. We'd probably have to discard the notion ofif..then..else.. altogether, and instead describe conditionals as futures or promises.I don't think that kind of a language could get much traction among humans (because asynchronicity), so the realistic option would be to ensure that the instructions humans can describe, are mappable to a hardware architecture that did things that way. Then again, I could be wrong; I often am.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 31, 2025, 10:31:10 am
content: Quote from: magic on January 31, 2025, 08:59:35 amYep. I'm not sure there's any magic approach to be found here. More like using different approaches for different use cases.Yes, speculative execution works well for single-threaded code. Interestingly though, where you often need raw single-threaded performance is more like scientific simulation, games, things like that. Things that can usually run on machines that are not nearly as vulnerable as servers, which OTOH lend themselves a lot more for heavy multi-threaded applications.So, as a first step, I would remove speculative execution altogether for CPUs meant for servers and stuff many more, and simpler cores in these. I'd keep speculative execution purely for CPUs used for workstation or gaming machines, for which the consequences of a potential exploit is normally much less severe. I don't even include all "desktop" use cases, as you definitely don't need speculative execution for running office software.And, even for those cases where the performance gain is useful, I would probably include provisions to dynamically disable speculative execution in the CPU when the load doesn't warrant that, or even possibly more globally as a security feature on a per-process basis (that would also require OS support). That could significantly limit the risks in case there's a known exploit.Just a few thoughts. It doesn't necessarily need to be all or nothing.

author: magic
author_rank: Super Contributor
timestamp: January 31, 2025, 10:54:49 am
content: Per process speculation disable would increase the cost of context switches, but maybe it could be an option for some.But IDK if web browsers would enable it, considering the impact on JavaScript benchmarks and the neverending growth of webshit complexity. Which brings us to my favorite rant topic: nothing in computing will really improve until SV is nuked and all current web developers sent to work minesCase in point, a leading vendor of internet access appliances apparently considers performance so important that they came up with new ways of speculation just when software thought that they have figured out how to trick the HW not to speculate in critical places and they only worry about consequences later. And still no fix either in HW or SW for months... I wonder if it's because the geniuses left no way to disable it or because beancounters consider the performance and PR impact not worth it.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 31, 2025, 11:11:45 am
content: Quote from: SiliconWizard on January 31, 2025, 10:31:10 amGames, definitely. Scientific simulations, I disagree. Everything I've worked with is better/faster when parallelized/distributed. There are a few simulators (mostly involving numerical solving of wave functions; stuff like DFT and so on, mostly quantum chemistry) that do single-shot solutions using a single thread, but they're pretty rare in my experience. Some are single-processor (possibly threaded) + GPGPU, but more because the developers had the hardware and funding, not because those simulators are best implemented that way. Most are parallel and distributed, typically on top of MPI.Quote from: SiliconWizard on January 31, 2025, 10:31:10 amFully agreed! When running some test simulator code on a single-purpose Linux node connected only to a LAN with no internet access, it's nice and useful to be able to disable the CPU mitigations (by booting withmitigations=offkernel parameter). I definitely do not do the same on my general purpose laptop I browse the web with.

author: DiTBho
author_rank: Super Contributor
timestamp: January 31, 2025, 03:18:07 pm
content: Quote from: Nominal Animal on January 31, 2025, 07:26:10 amWhen I look at { R10K, R12K, R14K, R16K }, all MIPS4/64bit superscalar high speculative, the speculative execution of these CPUs causes so many problems,- especially in cache coherency, which I'm currently working on - that I don't objectively know how it was possible to write kernels (including Linux) and firmware for multi-processor servers like DASH, with as many as 128 R10K in parallel.I took a close-up bite of systems with only 2xR14K CPUs, and that was enough to make me understand that I am too mind-limited to handle that crazy kind of stuff

author: ejeffrey
author_rank: Super Contributor
timestamp: January 31, 2025, 10:29:12 pm
content: Quote from: magic on January 31, 2025, 08:59:35 amOne problem here is that SMT is another cause of information leakage. By far the worse is with SMT + speculation, since threads sharing a core are exposed to each other's L1/L2 cache, and even lower level caches. But even without speculation this could be a problem.Quote from: SiliconWizardI think you could alternately blame the way sandboxes are used. Both of these bugs are presented with Javascript exploits accessing private browser information. I'm not sure if that's just for demonstration or if the vulnerabilities can also be exploited cross-process. But in general, I think executing untrusted javascript with a JIT in the same process as sensitive information might be the real problem. Processors and operating systems go to a lot of work to provide cross-process and user/kernel isolation, and memory is explicitly tagged with permissions. You can still have speculative execution flaws, but it seems to me you would have a lot better chance of preventing them.You could imagine a couple of ways to implement this. Javascript interpreters could be isolated to processes that use explicit message passing to communicate with the browser. That would be a performance hit, but would give the OS and CPU a much better chance to keep them isolated. Or you could implement an additional privilege level in the CPU specifically for sandboxing, basically letting the browser be it's own mini-operating system, and communication with the browser are done via the syscall mechanism.

author: ejeffrey
author_rank: Super Contributor
timestamp: January 31, 2025, 10:48:14 pm
content: Quote from: DiTBho on January 31, 2025, 03:18:07 pmI don't think it was possible. I think mostly the kernels for those CPUs were broken. They would work around problems as they showed up, with varying costs, and the expectations from the software was significantly less than now, so people got by. But there is a reason nobody designs CPUs like that any more.Recall that it was only in 2011 that a standard version of C/C++ introduced a proper memory model, following after Java which did so around IIRC 2005. It took years to come up with a consensus that this was even something we needed or what it should be. Prior to that, people were honestly mostly just doing whatever seemed to work on a particular platform at a particular time.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 31, 2025, 11:12:52 pm
content: Quote from: magic on January 31, 2025, 10:54:49 amYes, probably, although if going down that road, we should find ways to improve that.Alternatively, we could just avoid having to save/restore this in context switches by dedicating cores with speculative exec. enabled, and cores with it disabled, and schedule processes/threads accordingly. Which looks all the more possible if there are many cores.Quote from: magic on January 31, 2025, 10:54:49 amSurely if software itself can enable or disable it, that's sort of back to square one. That should probably be set with the appropriate permission. That would be doable for servers adminstrated (normally) by people who kind of know what they are doing. For "desktop" use, that's trickier. We could implement premade "profiles" that could be associated with a user account. But yes, with commercial OS's, software vendors would probably pressure OS makers to enable more performance for their specific apps. Ah well.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 02, 2025, 10:43:55 am
content: It does not help that the current process security models (outside of SELinux and such –– I'm not sure if macOS has similar) are too simple for our practical desktop needs, much less server service needs. (For example, no Apache suEXEC config can be fully hardened against script drops.)Consider the typical case where your browser renders and processes content in a dedicated slave process. Isolating it from other processes (except parent) and limiting it to specific subtrees of the filesystem, would be much better. (It is doable somewhat in Linux right now, usingseccomp aka Secure Computing, by filtering syscalls the isolated process; it is still sensitive to file descriptor leakage from the parent process.)Optimally, specific syscalls like open/link/unlink/mkdir/rmdir et cetera should be vettable by the parent process. (Linux seccomp alone does not suffice, but with seccomp and ptrace on Linux-5.4 and later, it is quite doable safely. The code is utterly Linux-only, though.)We cannot simply create a dedicated account for each user, because then the slave processes would run as the same user, and thus be able to communicate with each other. We need hierarchical identities, dynamically created user sub-accounts that only exist at run time, used for processes and process groups (in case some task needs sub-sub-processes or multiple processes in parallel, for example one to render content and run Javascript, and the other to decode media stream; they might even have completely different process and I/O priorities) and as a mark at each directory the sub-account may access.

author: DiTBho
author_rank: Super Contributor
timestamp: February 02, 2025, 11:22:21 am
content: Quote from: ejeffrey on January 31, 2025, 10:48:14 pmYup, talking about what I personally experienced in the 2000s:IDT eval boards, made for R2K (researching-only), R3K, R4K: 32bit/not speculative -> used in WinCE-v1-based devices (palmtops, ancestors of modern smartphones and tablets), Sony GameOS { Playstation1, Playstation2, .. } Nintendo GameOS { N64, ... }, VxWorks { Tektronix xp2xx, .. }, and GNU/Linux terminals and notebooks (made by IBM, sold, as far as I know, only in Japan). There were both hw and sw design references for which both the design model for the firnmware of the kernel, and the toolchains used were either based on Microsoft tools, or on the common binutils/gcc with some patches, but nothing earth-shattering.MIPS eval boards, made for MIPS32 { Atlas(1), Malta, ... }: 32bit/not speculative -> success, still used as "design reference" in routers { Fon1, Fon2, rb532a, rbm33g, RSPro, ...}. There were both hw and sw design references for which both the design model for the firnmware of the kernel, and the toolchains used were either based on Microsoft tools, or on the common binutils/gcc with some patches, but nothing earth-shattering.MIPS4/R1xK: 64bit/high speculative -> only used in SGI Workstations and Servers, with acustom toolchain (MIPSpro C/89 + dialectal #pragmas totally out of C-standard) and custom-kernel (Irix) which was "tailor-made" for the platform, revised for each individual machine { IP32r10k, IP30, IP35... }, and "held together" by what the developers themselves called "voodoo black magic", which means "if it works don't touch the code or everything will break"The only exception is the MIPS R5K, used in machines like the IP22: it is 64bit not speculative, and this translates into far fewer problems on both the hardware and software side, and it's no coincidence, in my opinion, that it's the only open-documentation released design, with the best GNU/Linux support right out of the box.In addition to this, there were very serious compatibility problems with the cache programmingCode:cpu_vendor = cpu_probe_vendor_get();switch (cpu_vendor){case NEC:cpu.cache.handler = cache_handler_NEC;break;case TOSCHIBA:cpu.cache.handler = cache_handler_TOSCHIBA;break;....default:panic(module, fid, "unknown vendor, I don't know how to manage the cache");break;}Toschiba vs NEC vs others, none of them respected any minimum standard, with the result that, as far as I was concerned, I had to do the "CPU_probe", understand who the vendor was, and then based on this select the specific methods for cache management. Add to this the fact that some CPUs {R12K, R14K, R16K, ... } don't even have public documentation.(1) except, buggy Philips chip

author: DiTBho
author_rank: Super Contributor
timestamp: February 02, 2025, 11:28:35 am
content: @Nominal AnimalI've seen distributions that run Firefox in a container.

author: DiTBho
author_rank: Super Contributor
timestamp: February 02, 2025, 11:40:26 am
content: Quote from: Nominal Animal on February 02, 2025, 10:43:55 amI don't know, so it's just my impression, but I think this is the direction Linus T.&C would all like to gowith the > 6.15 kernels to give a new strong "development reference" (1)on the userspace side to applications that are otherwise increasingly vulnerable.Kind of I add strong kernel side support, and provide several userspace side application examples,now follow them to rewrite more sensitive applications!Excellent, just ...... if it works for GNU/Linux ... it will take a while to become a "towing" directive for other kernels too?Especially for Haiku/OS which is very promising but is far behind ...And I would like to be FreeBSD, OpenBSD and then MacOS? Will they follow?

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 02, 2025, 02:41:46 pm
content: Quote from: DiTBho on February 02, 2025, 11:28:35 amSure. Containers are one possible solution, but not without their own limitations.Quote from: DiTBho on February 02, 2025, 11:40:26 amFreeBSD already hasjails, and macOSapp sandboxes. IIUC, OpenBSD rejected even BSD jails two decades ago. Linux also has namespaces for implementing somewhat similar containers.One can argue that containers are the solution, but then we get the current situation, where kernels cannot leak any information (via e.g. speculative execution) or security problems will ensue.If we had hierarchical runtime user account delegates (so that 'user' can control what 'user.delegate' has access to, but not vice versa), at least scheduling from an 'user.delegate' process to 'user' process would not need strong countermeasures against information leakage. Right now, we need those countermeasures everywhere (except on systems running only trusted code belonging to the same human or mutually trusting human group); even when scheduling between processes belonging to the same user.