17 ms·
New speculative attacks on Apple CPUs
- deleted 2y ago[deleted]
- anotherhue 2y agoFor any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading. https://spectreattack.com/ https://spectreattack.com/
- ajross 2y agoHm... as I read it this is much worse. Spectre/Meltdown were data isolation vulnerabilities. You could exploit side channel (mostly timing) information to intuit state about memory across a protection boundary. Basically you can prime the CPU state to allow you to tell which of multiple code paths the kernel/hypervisor/whatever took, and then go from there to reading arbitrary data. Which is bad, obviously. Here, they claim to have a remote exploit vulnerability. It's not that Apple is leaking data, it's that the CPUs have a bug where they appear to be actually executing code based on incorrectly-loaded ("predicted") data. Though the details are, as is usually the case, thin. I await further analysis.
- saagarjha 2y agoThey’re speculatively executing code. It’s not traditional code execution. (You can, of course, read the papers for full details.)
- omcnoe 2y agoIt's not remote code execution, it's the same flavor of "out of bounds read through speculation" as previous vulnerabilities. It's terrifying because they have a working proof of concept from untrusted JS in Safari, but there have been speculative execution in browser JS engines before now also.
- ajross 2y agoThe language seems to argue otherwise: SLAP "allows the adversary to jump the LAP to the target webpage's string and trick the CPU into operating on it" and FLOP "allows us to run a function with the wrong arguments". That's absolutely not mere data exfiltration. Now, maybe this is because of a trampoline based on pre-existing Safari bugs and not the CPU misfeature itself. Again, the details are slim. But "the same flavor of vulerability" seems to be a mischaracterization.
- saagarjha 2y agoNo, they’re correct.
- loeg 2y agoOnly speculatively. The end result is the same as not executing that code, other than observable side effects.
- yencabulator 2y agoMy read: the attack gets 600 cycles of CPU time to execute its code (JITted Javascript, in web context) on the speculated data, and to use some side channel to communicate results back out of the speculated parallel-world. Some of the earlier speculation attacks didn't get to do arbitrary compute on the speculated data, they could only for example influence whether something was loaded into cache or not. This makes an attack easier to write.
- midtake 2y agoA browser-based attack, in theory, could have happened with Spectre/Meltdown as well. I seem to recall a PoC for Spectre in the browser, actually. I believe it's also a reason that microsecond precision in the browser was made a bit more opaque since that era.
- mettamage 2y agoGLitch was a Rowhammer browser based attack [1]. It's not Spectre/Meltdown but still, for a while people thought it couldn't be done. [1] https://www.vusec.net/projects/glitch/ https://www.vusec.net/projects/glitch/
- umvi 2y agoIs it bad that I disable spectre mitigations on all my PCs to get a free double-digit-% performance boost?
- kllrnohj 2y agoWhat are you doing where you see anything remotely close to double-digit-% gains from disabling spectre mitigations?
- umvi 2y agomy specific use case where I see significant performance improvement is image segmentation pipelines (which involve opencv-style image processing and AI inference). YMMV depending on your CPU I suppose.
- iforgot22 2y agoVideo editing maybe? Which is not going to involve running untrusted code.
- kllrnohj 2y agoIt's not going to hammer on syscalls, either, so it won't have any spectre-related regressions.
- AHTERIX5000 2y agoIf mitigations include disabling SMT and the workload is compiling code, then the difference is easily in double digits.
- kllrnohj 2y agoWhat OS ships the mitigation of disabling SMT by default? Surely they just meant things like the retpoline mitigations in syscalls?
- baq 2y agoOnly if you don't care if baddies see you go fast
- LPisGood 2y agoI’d highly recommend reading Flush+Reload first since the cache side channel is key to any of these miceoarchitectural attacks.
- mettamage 2y agoAs someone who followed a course on all of this, this is indeed how we started out. 1. Read Flush + Reload 2. Then reproduce it in C 3. Then read Meltdown 4. Reproduce it in C 5. Read Spectre 6. Reproduce it in C After that we had to implement a VUSEC paper. I chose GLitch [1]. [1] https://www.vusec.net/projects/glitch/ https://www.vusec.net/projects/glitch/
- sabas123 2y agoKeep in mind that getting meltdown to work might be very difficult depending on your setup. I wouldn't have been able to at least when starting out my teacher didn't provide us with targetable hardware. A spectre (particularly RSB-based ones) are nice to start out with imo.
- mettamage 2y agoYea fair, this is obviously a high level overview. I think I found with meltdown that I needed the assembly code. I also was able to reproduce it with actual C code if I recall correctly but that was way more finnicky.
- tptacek 2y agoAside: I feel like RUB has become kind of a global center for this kind of high-end offensive security work. Was I just not paying enough attention 10 years ago or is this a new-ish thing?
- jf 2y agoWhat is RUB?
- pulvinar 2y agoRuhr-University Bochum, in Germany
- stoneforger 2y agohttps://www.ruhr-uni-bochum.de/de https://www.ruhr-uni-bochum.de/de
- dooglius 2y agoRuhr University Bochum, the third author's University
- deleted 2y ago[deleted]
- bobnamob 2y agoIdk if it's RUB or Yuval, he was credited on spectre and meltdown as well (if I recall correctly), but he was at data61 or Uni adelaide at the time
- r9295 2y agoThey've also consistently put out some of the best fuzzing research
- tptacek 2y agoTheir offensive crypto work is also on point.
- 2y ago
- remus 2y agoInteresting that the researchers have gone public before a mitigation is in place from Apple. Seems in pretty stark contrast to the industry-wide coordination that went into patching and mitigating spectre.
- dartos 2y agoDoes Apple pay bug bounties?
- InTheArena 2y agoYes, they do.
- saurik 2y agoThey claim to, but they drag their feet, demand terms most researchers find so unacceptable as to be a bit immoral (the point of "responsible disclosure" isn't, in fact, to hold secrets from the public arbitrarily long), and often end up paying only a fraction of what was expected, if anything. https://pxlnv.com/linklog/apple-bug-bounty-troubles/ https://pxlnv.com/linklog/apple-bug-bounty-troubles/ https://www.marketplace.org/shows/marketplace-tech/looking-for-worms-in-apple-leaves-a-bad-taste-in-ethical-hackers-mouths/ https://www.marketplace.org/shows/marketplace-tech/looking-f... https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-apple-security-bounty/ https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
- tptacek 2y agoThe vibe I got talking to people like Mark Dowd about this is that they're running something closer to an exploit bounty program, and it's pretty focused on patterns of vulnerabilities common to some pretty specific threat actors.
- threeseed 2y agoYour links are all from 2021. I remember there was a lot of criticism at the time and so they updated their bug bounty program which quite a number of changes: https://security.apple.com/blog/apple-security-bounty-upgraded/ https://security.apple.com/blog/apple-security-bounty-upgrad... Would be interesting to see if it made a difference.
- gjsman-1000 2y agoBizarre the M1 is immune to both; I'm more secure by not upgrading. (Sure, there's still a few, but they are mostly minor by comparison, or newer chips are also affected.)
- sodality2 2y agoNewer CPUs use more and more "hacks" - out of order execution, caching, speculative execution, branch prediction, etc - to gain performance improvements. The further back you go, the less vulnerable CPUs generally are to these (but possibly more vulnerable to other kinds of attacks).
- badgersnake 2y agoIndeed, my Apple Watch (series 3) has always been immune to all spectre type attacks, the CPU is too simple. It doesn’t do speculative execution at all.
- hinkley 2y agoI can’t imagine taking a cpu design class in this more cynical era. So much of the speed these days seems to come down to distilling smoke and mirrors into physical form.
- sodality2 2y agoOn the other hand, research into finding these vulnerabilities seems to be booming. Though presumably, so is the grey-hat market.
- School-Cotton 2y agoBut M1 is squarely a modern CPU. It uses all the techniques you mention (as does every high-performance CPU since the Pentium Pro era).
- sodality2 2y agoFor sure. But the further you go along, the _more_ of these tricks it uses and relies upon to improve performance. New vulnerabilities that are discovered are likely to take advantage of some feature on the spectrum of these “hacks”, from new to old. Because older “hacks” are well-known and studied, newly discovered vulnerabilities are more likely to target features in the newer end of that spectrum (AKA newer CPUs).
- junek 2y agoOK, fun. What can we do to mitigate this until it gets patched?
- thijsr 2y agoFrom the FAQ: > While FLOP has an actionable mitigation, implementing it requires patches from software vendors and cannot be done by users. Apple has communicated to us that they plan to address these issues in an upcoming security update, hence it is important to enable automatic updates and ensure that your devices are running the latest operating system and applications.
- omcnoe 2y agoSerious answer, don't use Safari. Use a browser that properly separates webpages into isolated processes so that this kind of cross-site read is not possible.
- amelius 2y agoWill that work? Isn't memory treated in a unified way between processes, at some point?
- goldsteinq 2y agoIt will work unless someone forgets to add a public suffix into the public suffix list (as described in the FLOP paper). Both of these attacks target virtual memory pointers.
- saagarjha 2y agoProcessors are not supposed to speculate across ASIDs
- goldsteinq 2y agoThere’re no other browsers on iPhone. Every iPhone browser is a reskin of Safari. They’re in theory supposed to allow other browsers in the EU, but AFAIK it has not happened yet.
- omcnoe 2y agoTheir SLAP demo provides a great example of how defence-in-depth can make/break the viability of an exploit. That terrifying Safari demo is possible because Safari fails to isolate new windows in individual processes when calling `window.open` in js. All the other side channel magic presented here doesn't matter if the data you want to read is in a seperate process with sufficient separation from the "hostile" process in the address space.
- r00fus 2y agoDo other browsers have process isolation for new tabs?
- tptacek 2y agoNot necessarily for tabs on the same web site, but for different sites, yes. Hence "site isolation".
- lxgr 2y agoTo be fair, this is (relatively, compared to the age of the web) new behavior though. Even Chrome, which pioneered the "tab per process" model, didn't isolate same browsing group context sites for a long time, and still shares processes on Android as a resource optimization: https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md#Full-Site-Isolation-site_per_process https://chromium.googlesource.com/chromium/src/+/main/docs/p... Firefox only released their "Project Fission" in 2021, i.e. three years after Spectre.
- lxgr 2y agoThat's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1]. By setting a different policy, sites can protect themselves against this. I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a major performance hit, and I don't think any other browsers do it differently. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr...
- tptacek 2y agoCool detail, in the section where they reverse-engineer the presence of an LVP on the M3: Remarkably, while all other load widths activate the LVP on any constant value fitting that width, we observe that acti- vation on 8-byte wide loads occurs only when the load value is zero. We conjecture that this may be a countermeasure for memory safety such that the LVP will not learn values of pointers. That is, with the M3 being a 64-bit CPU, pointers are 8 bytes wide. Furthermore, on 64-bit macOS executables, any virtual address below 0x100, 000, 000 is invalid.
- ijustlovemath 2y agowait, so does this mean that if an exploit tries to use a 32 bit address it's immediately shut down?
- anyfoo 2y agoThere are usually no valid 32 bit addresses, i.e. the first 4GB are not mapped.
- avianlyric 2y agoThat might be their point. As the OP quoted > any virtual address below 0x100, 000, 000 is invalid. That kinda suggests that all 32bit addresses are inherently invalid on 64bit MacOS
- 2y ago
- sylware 2y ago... and another one...
- resource_waste 2y agoGood reminder that Marketing is detached from reality.
- saagarjha 2y ago> On the other hand, although Chrome is equipped with Site Isolation, we demonstrate that it is not a perfect mitigation. We show the real-world existence of corner cases, where two subdomains of the same site can be merged into one process, again leading to LAP- and LVP-based attacks. Did anyone spot where this is mentioned? Edit: it doesn’t seem like they have a general attack. Rather, it’s that some sites are not in the public suffix list. Edit 2: It’s also interesting that they found that iPhone 13 and iPhone 13 mini (which have the same processor and came out at the same time) differ in LAP in that they observed only the latter as having it. Very curious…
- hashstring 2y agoRight, and “where two subdomains of the same site can be merged into one process” is normal right, given Site Isolation ≠ Origin Isolation. A PSL flaw is important, but also a low-cost fix. Thanks for pointing this out.
- daneel_w 2y agoApple released minor-version updates to both macOS and iOS the past few days, both containing several security fixes. Has anyone been able to confirm if they address these exploits?
- layer8 2y agoThey haven’t yet. From https://www.bleepingcomputer.com/news/security/new-apple-cpu-side-channel-attack-steals-data-from-browsers/ https://www.bleepingcomputer.com/news/security/new-apple-cpu...: Apple acknowledged the shared proof-of-concept and stated it plans to address the issues. However, at the time of writing, the flaws remain unmitigated. "We want to thank the researchers for their collaboration as this proof of concept advances our understanding of these types of threats," Apple told BleepingComputer. "Based on our analysis, we do not believe this issue poses an immediate risk to our users."
- trompetenaccoun 2y agoIt's crazy that they were informed about this months ago and still have not fixed it yet. They're going to have to now that it's public but why would that pressure even be needed. I naively assumed if Apple still gets one thing right it's security updates. This is disappointing and concerning.
- remram 2y agoHave you considered that it might be difficult?
- c00lik_5 2y ago[flagged]
- bawolff 2y agoHmm, one part i found interesting > In order to make cache hits distinguishable from misses in Safari, we reference the NOT gate-based cache amplifica- tion primitive from [29, Section 5], adjusting the speculation parameters for the M2 CPU. We run the amplifier 500 times when the target address is cached and 500 more times when it is evicted, in native and WebAssembly implementations. Table 3 summarizes the timing distributions, with units in ms. We observe that they are clearly separable even in a web environment, allowing us to distinguish cache hits from misses with WebKit’s 1 ms timer. So i guess all the hub hub around disabling fine resolution timers and SharedArrayBuffer was for naught.
- kevingadd 2y agoIt delayed viable attacks by a few years, maybe? It doesn't hurt that setbacks for web app development coincidentally send developers into the open arms of Google and Apple's stores that collect a 30% cut of all revenue, so there was a good incentive to do it even if it didn't protect anyone.
- bawolff 2y ago> It doesn't hurt that setbacks for web app development coincidentally send developers into the open arms of Google and Apple's stores that collect a 30% cut of all revenue, so there was a good incentive to do it even if it didn't protect anyone. That seems like a bit of a reach. Its an obscure feature that is rarely useful, and when it is all you have to do is send the right http header (if using chrome) and you get it back.
- kevingadd 2y agoMultithreading may be an obscure feature to you but runtime developers get requests for it all the time. SAB becoming widely available was definitely delayed.
- bawolff 2y agoI would still maintain that needing multithreading on a website is relatively rare, and specifically needing SharedArrayBuffer instead of just multiple proceses (e.g. webworkers) is even more rare. Did use cases exist? Sure. But not sufficiently to move the needle on app store usage.
- yoshicoder 2y agoFunny that I am seeing this now, because last Fall I had Daniel Genkin as my Intro to Cyber Security Professor (co-author of this result). Interesting class, but I remember him mentioning that they were working on a speculative attack for Apple CPUs after seeing the results of spectre and meltdown on Intel CPUs. I remember how he seemed almost paranoid about security, and I suppose I see why now (security is almost never guaranteed). Especially now that I have just bought an M4 mac
- kd913 2y agoAm curious if the problem impacts m4 given it came out after this was released and disclosed. That and it moved to Arm’s 9.2 instructions.
- artisanspam 2y agoThe marketing culture for announcing hardware exploits is so strange to me. The norm seems to be getting a custom domain, logos, demos, an FAQ... why do all this instead of just reporting the exploit and releasing a paper?
- 9283409232 2y agoOnly academics read exploit papers. I don't see anything wrong with releasing the information is a more digestible way if it is something that affects the general populace. I only knew about heartbleed because of the website. https://heartbleed.com/ https://heartbleed.com/
- caust1c 2y agoBlame society. Businesses won't value security unless the fear of getting attacked is sufficiently strong and the losses significant. Otherwise why invest in it at all? Definitely not just hardware exploits though. Look at heartbleed for example. It's been going on a long time. Hardware exploits are just so much more widely applicable hence the interest to researchers.
- nicce 2y agoIt also feels like that people who are highly determined to build high quality, secure software are not valued that much. It is difficult to prove their effort. One security-related bug removes everything, even if it happened only once in 10 years in 1 million line code base.
- woodruffw 2y agoHeartbleed et al. demonstrated conclusively that recognition matters; I don't begrudge researchers any technique that increases the relative visibility of their work.
- IshKebab 2y agoIt's a recent trend basically since Heartbleed had a cool name and lots of press. Why would you not want your exploit to be well known and to get lots of credit for it? If anything it's surprising it didn't happen earlier.
- twoodfin 2y agoThis introduced me to the idea of load value predictors. Is Apple the only chip designer using these in commercially released microarchitecture?
- eigenform 2y agoProbably not, but I don't think anyone has talked about it explicitly. Otherwise, there are known examples of related-but-less-aggressive optimizations for resolving loads early. I'm pretty sure both AMD[^1] and Intel[^2] have had predictive store-to-load forwarding. edit: Just noticed the FLOP paper also has a nice footnote about distinguishing LVP from forwarding during testing (ie. you want to drain your store queue)! [^1]: https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/white-papers/security-analysis-of-amd-predictive-store-forwarding.pdf https://www.amd.com/content/dam/amd/en/documents/processor-t... [^2]: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/fast-store-forwarding-predictor.html https://www.intel.com/content/www/us/en/developer/articles/t...
- bjackman 2y ago> I'm pretty sure both AMD[^1] and Intel[^2] have had predictive store-to-load forwarding. IIRC this was how Spectre Variant 4 worked.
- adgjlsfhk1 2y agofrom doing some work on GC a couple years ago, at that time apple was the only one with it. The performance is awesome, it makes graph traversal ~2x faster.
- adrian_b 2y agoIn many CPU ISAs, load value predictors are unlikely to be useful, because they cannot guess the value that will be loaded with an acceptable probability. The ARM ISA and also other ISAs with fixed-length instruction encoding are an exception. Because they have a fixed instruction length, typically of 32 bits, most constants cannot be embedded in the instruction encoding. As a workaround, when programming for such ISAs, the constants are stored in constant pools that are close to the code for the function that will use them, and the load instructions load the constants using program-counter-relative addressing. Frequently such constants must be reloaded from the constant pool, which allows the load value predictor to predict the value based on previous loads from the same relative address. In contrast with the Apple ARM CPUs, for x86-64 CPUs it is very unlikely that a load value predictor can be worthwhile, because the constants are immediate values that are loaded directly into registers or are directly used as operands. There is no need for constants stored outside the function code, which may be reloaded multiple times, enabling prediction. All fast CPUs can forward the stored data from the store buffer to subsequent loads from the same address, instead of waiting for the store to be completed in the external memory. This is not load value prediction.
- 10000truths 2y agoRelated is Casey Muratori's explanation of the GoFetch speculative attack on Apple's M-series CPUs: https://www.youtube.com/watch?v=uZEBkOrfUzM https://www.youtube.com/watch?v=uZEBkOrfUzM
- api 2y agoI bet you could construct a hard proof that any kind of speculation is insecure in the sense that it cannot be proven secure. If that's not true, then someone's going to figure out exactly how to set bounds on safe speculation and that will become part of future CPU designs.
- deleted 2y ago[deleted]
- ______ 2y ago> This research was supported by the Air Force Office of Scientific Research (AFOSR) I wonder if this is the kind of grant that is no longer being funded (or at least "paused")
- WhyNotHugo 2y agoIf I understand correctly, this also affects Asahi Linux, right?
- saagarjha 2y agoIt’s a processor attack so yes
- everfrustrated 2y agoYes. They even used Asahi Linux to develop their techniques on as it gave better access to cpu controls. The exploit was tested on Safari (IE not a Linux fault but a CPU one).
- hk1337 2y agoI'd really be curious to recreate this or to know if any of their results included using private browsing mode? I only bring it up because one of the reasons I use Safari with private browsing as a default is because, if I were to login to a site like Facebook in one tab, open a new private tab in the same window and try going to Facebook, it would not recognize that I had already logged in from the other tab. Chrome nor Firefox do that.
- peterburkimsher 2y agoCould this attack be used to jailbreak the latest iPhone?
- saagarjha 2y agoNo.
- alphabetting 2y agoIs the statement from Apple just PR or is this not a usable exploit? "Based on our analysis, we do not believe this issue poses an immediate risk to our users." https://www.bleepingcomputer.com/news/security/new-apple-cpu-side-channel-attack-steals-data-from-browsers/ https://www.bleepingcomputer.com/news/security/new-apple-cpu...
- keyle 2y agoApple PR, which is unlike them; to wave it off.
- hashstring 2y agoThey carefully added “immediate”.
- rasz 2y ago>statement from Apple just PR remember the iphone 6 battery and butterfly keyboard gate we both "small number of users" according to Apple.
- bjackman 2y agoCPU vendors always say this when an exploit is published before they mitigate. Sometimes they mean "no we don't think it's exploitable", sometimes the charitable reading is "we don't think anyone is exploiting this and we think developing an exploit will take quite some time". Unfortunately they never reveal exactly that they mean. This is very annoying, because when it's the former case, they're often right! Security researchers publish bullshit sometimes. But the vendors basically leave you to figure it out for yourself.
- philodeon 2y agoGiven that the researchers published working exploits that you can modify for your own use, it’s PR.
- fulafel 2y agoAnd from the paper seems like they played it interestingly in the researchers direction as well: "1.2. Responsible Disclosure We disclosed our results to Apple on May 24, 2024. Apple’s Product Security Team have acknowledged our report and proof-of-concept code, requesting an extended embargo beyond the 90-day window. At the time of writing, Apple did not share any schedule regarding mitigation plans concerning the results presented in this paper. "
- anonymous1213 2y agoA great hack
- aucisson_masque 2y ago> As pointed out by iLeakage, Safari lacks Site Isolation Well I'm shocked, for such a company that promotes security and privacy, apple not having put site isolation into safari seems amateurish.
- School-Cotton 2y agoApple promotes privacy, sure. I'm not sure whether they promote security. Of course they are not against security, but I don't remember it being a significant theme in their marketing.
- aucisson_masque 2y agoI believe it's implied when they say 'what happens on your iphone stays on your iphone'. You can have security without privacy but you can't have privacy without security, when they promote privacy they also claim to be secure. No website isolation goes against both of these principles.
- lern_too_spel 2y agoI consider the world lucky that the Apple apologists haven't emboldened Apple to prevent its customers from using other browsers on their Macs... yet.
- wswin 2y agoI'm penchant toward disabling js by default on untrusted sites. It's basically someone's programm that we run on our machine and apparently we not yet can do sandboxes
- tmshapland 2y agoGreat post, so interesting!
- phendrenad2 2y agoSeems like speculative execution is just fundamentally insecure. With SPECTRE/MELTDOWN mitigations, doesn't CPU performance drop below the same CPU performance with no branch prediction at all? Should we move back to CISC? Or maybe VLIW?
- andrewia 2y agoI don't think so; speculative execution is the cornerstone of modern CPU performance. Even 15-year-old 32-bit ARM CPUs do it. The only phone/PC-grade processors without it are the first generation of Intel Atom, and I recall that early Atom processors sacrificed a ton of performance to keep power consumption low. I doubt this will change since mitigations are "good enough" to patch over major issues.
- happosai 2y agoThere is extremely popular Cortex-A53 which is in-order core.
- MindSpunk 2y agoYes and it's very slow as a result. In-order cores without speculative execution can't be fast. Not unless you have no memory and only operate out of something equivalent to L1 cache. Memory is slow. Insanely slow (compared to the CPU). You can process stupid fast if your entire working set can fit in a 2KB L1 cache, but the second you touch memory you're hosed. You can't hide memory latency without out-of-order execution and/or SMT. You fundamentally need to be parallel to hide latency. CPUs do it with out-of-order and speculative execution. GPUs do it by being stupidly parallel and running something like 32-64 way SMT (huge simplification). Many high-performance CPUs do all of these things. Instruction level parallelism is simply not optional with the DRAM latency we have.
- happosai 2y agoCortex a53 may be slow, but it's fast enough for very many tasks. Once you design the your data structures to fit L1/L2 caches it actually is pretty damn fast. Best part of cache aware data structure design it also makes code run faster on Out Of Order CPUS. A53 is of course slow if you use modern layer-upon-layer-ware as your architecture. But I was just really trying to point that in-order cpus are still around, they did not disappear with in-order atom.
- qquestionne 2y agoCan browser side channel attacks be made less effective by running another compute/branch heavy process?
- akdor1154 2y agoMine shitcoins in a web worker for extra protection?
- qquestionne 2y agoSure. Why not? It'd tick a couple of the boxes to possibly lower the exploit bitrate... "Side channel attacks are a class of exploit that infers secrets by measuring manifestations such as timing, sound, and power consumption"
- lincpa 2y ago[dead]
- worthless-trash 2y agoThis isn't just limited to safari. I wonder if this apple fix this more thoroughly than spectre and meltdown.
- TheAtomic 2y agoTidal
- ingohelpinger 2y agoSo this attack is still possible even with lockdown mode on?
- saagarjha 2y agoYes.
- Malidir 2y agowhy?
- saagarjha 2y agoIt’s a processor bug
- ingohelpinger 2y agoDoes this mean we should all get rid of our macs now ?
- saagarjha 2y ago¯\_(ツ)_/¯
- deleted 2y ago[deleted]
- BobbyTables2 2y agoThere are two times in a man's life when he should not speculate: when he can't afford it, and when he can. Mark Twain
- gpderetta 2y agoCPUs on the other hand do nothing but speculate.
- kapitanluffy 2y agodoes it affect gecko browsers? firefox?