chars1ub0w
macrumors 6502a
With the M6 reportedly not using TSMC’s best 2nm process (N2 vs. N2P node), will M6 frequencies not receive much of an uptick? The M3 to M4 jump was huge.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
M4+ Chip Generation - Speculation Megathread [MERGED]
- Thread starter GoetzPhil
- Start date
- Sort by reaction score
IvyKing
macrumors 6502a
About to slow down??? Between 1980 and say 2003, processor speeds went from 8 MHz to 1+ GHz, for over a factor of 100 increase in speed. Since then we've seen maybe a factor of 3 - 4 increase. The major increase in throughput has been a combination of executing more instructions per clock on a single core and more cores running in parallel.
Secure your app with Memory Integrity Enforcement - Meet with Apple - Videos - Apple Developer
Discover Memory Integrity Enforcement (MIE), a new security technology where hardware, the operating system, and the compiler work...developer.apple.com
First public macOS kernel memory corruption exploit on Apple M5
Apple spent five years building hardware and software to make memory corruption exploits dramatically harder. Our engineers, working together with Mythos Preview, built a working exploit in five days.
blog.calif.io
throAU
macrumors G4
First public macOS kernel memory corruption exploit on Apple M5
Apple spent five years building hardware and software to make memory corruption exploits dramatically harder. Our engineers, working together with Mythos Preview, built a working exploit in five days.
Nothing is ever 100% secure.
Think of ANY additional feature as an additional hurdle. This does not make the advancements that Apple have made pointless, and you can bet that lessons learned will go into M6, and lessons learned there into M7, etc.
M4 and previous generation are much easier to exploit.
It's more than just that. Obviously until we know details all one can do is speculate, but I suspect this is much like the ForcedEntry exploit.
Recall that one type of zero-click exploit against messages was to craft media files (JPEG, PDF, GIF, whatever) that exploited a bug in the code parsing such media files. Once the parsing goes wrong, you have control of the Messages process which at the very least gives you access to the messages and contacts of the victim.
Apple supposedly fixed this by creating a second process, called Blastdoor, in which media are parsed. So if there's a bug in parsing (and there will be, for a while, because parsing these formats can be so tricky) all you achieve is control of the Blastdoor process which has few permissions and can't do very much of interest.
Even so, soon after Blastdoor was released, an exploit named ForcedEntry was able to gain access into Messages. How?
Well, not EVERY media file was routed through Blastdoor! For reasons that, in retrospect, look dumb and foolish, GIFs used in a very particular context were considered trustworthy (eg GIF is not that complex a format to parse) and so were still parsed inside the Messages process, not via Blastdoor. So when a Trojan GIF was encountered, game over! (And in fact the underlying intuition, that GIF is simple and safe, may well have been correct. The problem is that not everything that claims to be GIF is in fact GIF! The Trojan .gif file was treated as gif by Messages, but then recognize by the parsing code as a mislabeled .TIFF file. Which could exploit bugs in TIFF parsing...)
Point is, locks only work if you lock EVERY door in the house. Blastdoor was a good idea, foiled by bad assumptions in the surrounding code. As far as I know, after the GIF foolishness that allowed for ForcedEntry was shut down, Messages and Blastdoor have not been cracked since.
My guess is we have the same thing here. The overall architecture of MTE (both the hardware side and the OS side) are correct, but to be safe, every part of the system has to use MTE. What I expect we will find is something like some driver was
1. not compiled with MTE AND
2. not 100% confined to userspace. (Most drivers are now in userspace so that even if they are exploited, like Blastdoor, all that exploit gets you is control of that userspace process which has limited capabilities and permissions. Those that have to communicate with the kernel are supposed to use something like XPC that limits their ability to manipulate kernel memory.)
We'll probably find some driver that's ten years old and hasn't been touched in eight years, that people assumed was safe [like GIF], so not worth retrofitting with MTE and XPC, but the assumption of safety [like GIF] could be worked around via "lying" to the system (eg maybe a driver that decodes JPEG in HW, but you give it a malformed JPEG file...)
Sydde
macrumors 68030
The original Apple II had a 1MHz 8-bit Processor in the late '70s; the 64-bit PowerMac G5 reached 2.7GHz just under 30 years later. That is a factor of 2700, and nearly 9 times faster than the G3 iMac about 8 years earlier. But, you have to consider scale: 5GHz is slightly less of an overall jump compared to the total gain of the first 30 years.
We have gone from µ-scale ICs to lower n-scale ICs, and the issues with mastering those smaller scales are non-trivial. In total gain, we are a little ahead of where we were, but we are also reaching the lower limit. At 1Å, the process will be right on top of the actual size of the atom of silicon. Most gains henceforth will be in operational design, and it is unlikely that clock speeds will sustainably pass the 7GHz mark.
IvyKing
macrumors 6502a
The Apple II was announced at the "First West Coast Computer Faire" in April 1977 - I've got one of the original flyers from the event somewhere in my collection. My recollection was that 2MHz and possibly 4MHz 8080's and Z-80's were being sold at that time. Seattle Computer Products was working on their 8 MHz 8086 board in 1979, and they were running MS's standalone disk BASIC on it in Nov 1979. Their 8086 system was offered for sale in 1980, hence my 8MHz figure for 1980. Going back a few more years, the 8008 had a sub 1MHz clock speed.
Sun's Niagara processor was a bit ahead of its time with the focus on throughput as opposed to single core performance. A book on Posix threads published by Sun in the late 90's specifically mentioned that threads only made sense if the code was intended to run on a multiprocessor (or multi-core) machine. An early example of running multiple instructions at the same time was the mid-60's CDC6600 that had multiple specialized functional units so more than 1 instruction could be executed at the same time.
One limit on processor speed comes from the on-chip "wires" connecting the various circuits act as RC transmission lines, where the propagation times go up with the square of the distance. This gets worse as the features shrink.
Another issue is that the feature size is approaching the "uncertainty" (indeterminate is more accurate) limit, where conductors and insulators are no longer well defined.
On another note, the Apple I had the option of using a 6800 as well as the 6502. I wonder if things would have turned out a bit differently if the Apple II used the 6800. Microware's OS-9 could multitask on a 6809 micro, such as the Tandy Color Computer. The downside would have been the lack of a compatible upgrade path as Intel had with the 8086 to the 80286 and even better the 80386.
Sydde
macrumors 68030
The 6502 was low-cost, simple and fast. The advantages of the 6800 were minimal in comparison. If multitasking were a real consideration for home computers at the time, building the basic circuitry to support it (op-code parsing for dynamic z-page, stack and banked memory) would not have been much of a lift. The 6800 was good but kind of clunky in comparison.
At present, it looks like CPU performance has itself hit a different sort of wall. For most tasks, greater efficiency is not really needed. 4GHz, 5GHz, 6GHz, there is not really that much to gain. The serious work is the stuff that gets done in the GPU, and raising the clock is not necessarily the best approach for embarrassingly parallel work, or even moderately parallel work.