What does moving to a different process node (TSMC N3B to N3E/N3P) family mean for security updates and long term support?

[Mity]

This was a great video analyzing Apple's M3 family chip designs based on N3B:

At the end of the video, he suggests that Apple may move to N3P directly from N3B.

Separately, MaxTech released a video recently, speculating that Apple may release an updated M3 Mac Studio with an M4? Ultra chip based on N3E:

Despite the difference in viewpoint on moving to N3P or N3E, one thing remains the same, which is that Apple will have to re-design N3E and N3P chips since these two are not part of the N3B family. But N3E and N3P are part of the family so an N3E design can be ported to N3P in the future.

What is the implication for security updates and long term support for an N3B Mac? Is it possible that security vulnerabilities may exist for N3B-based chip designs but not N3E/N3P-based ones? Is it costly (time and money) for Apple to continue supporting N3B for 6 or 7 years, despite the rest of the industry skipping N3B?

 

[galad]

From the point of view of software, it means exactly nothing.

 

[leman]

What is the implication for security updates and long term support for an N3B Mac? Is it possible that security vulnerabilities may exist for N3B-based chip designs but not N3E/N3P-based ones? Is it costly (time and money) for Apple to continue supporting N3B for 6 or 7 years, despite the rest of the industry skipping N3B?

Any physical update (be it a redesign or a tweak) introduces a chance to fix or create a new hardware vulnerability. It is very unlikely that Apple will actually patch vulnerabilities in hardware. So once a chip is designed, that's likely it. They can continue producing it for as long it is commercially viable, I don't believe they will do anything more than that.

Are there any particular vulnerabilities you are thinking about? Things that have to do with speculative execution are not easy to patch and will require a substantial redesign of the hardware. Or even better, an overhaul of the software model. We should finally accept that secure computing is not compatible with performance, and introduce "secure computing" modes that would disable speculative execution and other exploitable features of a CPU core.

 

[Mity]

Are there any particular vulnerabilities you are thinking about?

No, I'm just thinking about what Intel had to go through with Spectre, Meltdown and Downfall. As you said, any redesign presents a risk of a new vulnerability but the question is how much attention will Apple pay to an older, obsolete chip design? Because M1 series have been excellent, few people are upgrading and I don't know what means for LT support from Apple on a line that will not have high sell through.

That's what I'm trying to grapple with as I consider a new Mac. The specs that I want will take the price up to $5500+ and I want a solid performance for the next 7ish years without fear that patches will be available ASAP and no Apple Silicon machine will be neglected.

 

[leman]

No, I'm just thinking about what Intel had to go through with Spectre, Meltdown and Downfall. As you said, any redesign presents a risk of a new vulnerability but the question is how much attention will Apple pay to an older, obsolete chip design? Because M1 series have been excellent, few people are upgrading and I don't know what means for LT support from Apple on a line that will not have high sell through.

That's what I'm trying to grapple with as I consider a new Mac. The specs that I want will take the price up to $5500+ and I want a solid performance for the next 7ish years without fear that patches will be available ASAP and no Apple Silicon machine will be neglected.

If there is a real hardware vulnerability, there is not much they can do. Of course they will be releasing software patches and workarounds for as long as the hardware is officially supported.

 

[za9ra22]

Apple don't really have any alternative than to continue support for existing products that are in or heading towards the hands of consumers, so as much as new Apple Silicon may be engineered to overcome the hardware vulnerabilities the M-series processors have at present, there will still have to be mitigation for potential threats exploiting it.

Aside from the huge reputational hit which could in itself prove fatal to the company for abandoning all the current M series products in use, there's the fact that the vulnerability itself is in the nature of the pre-fetch functionality of the processor. Apple can't fix the root of the vulnerability, but they can engineer system level blocks against exploiting it.

Importantly, this vulnerability has been known for a couple of years already, yet no known exploits exists for it, which means that it is not exactly easy to exploit it. It isn't as simple as a piece of malware being dropped from a compromised website or email attachment. All in all, whilst I wouldn't say it is unimportant, I would say that the only reason you haven't seen Apple talking about what they're doing in relation to it, is because they almost never discuss these things in public anyway. They do discuss them with security researchers and mitigation teams.

Meaning that:

No, I'm just thinking about what Intel had to go through with Spectre, Meltdown and Downfall. As you said, any redesign presents a risk of a new vulnerability but the question is how much attention will Apple pay to an older, obsolete chip design? Because M1 series have been excellent, few people are upgrading and I don't know what means for LT support from Apple on a line that will not have high sell through.

That's what I'm trying to grapple with as I consider a new Mac. The specs that I want will take the price up to $5500+ and I want a solid performance for the next 7ish years without fear that patches will be available ASAP and no Apple Silicon machine will be neglected.

This isn't of the same nature of problem as Intel's vulnerabilities, because Intel could only manage the processor end of these issues. In Apple's case, the M-series is their design, the hardware is under their control, and the operating system knitting it all together and controlling it is too. Amongst other things, it means that you won't hear much, if anything at all, about the reaction since there are no outward public-facing channels of communication, and they can engineer low level encryption (for example) to shield pre-fetch data and packet size, without impacting the user.

Most risk to the system is at the user level, hence the safeguards already in macOS.

 

[dmccloud]

No, I'm just thinking about what Intel had to go through with Spectre, Meltdown and Downfall. As you said, any redesign presents a risk of a new vulnerability but the question is how much attention will Apple pay to an older, obsolete chip design? Because M1 series have been excellent, few people are upgrading and I don't know what means for LT support from Apple on a line that will not have high sell through.

That's what I'm trying to grapple with as I consider a new Mac. The specs that I want will take the price up to $5500+ and I want a solid performance for the next 7ish years without fear that patches will be available ASAP and no Apple Silicon machine will be neglected.

Most Apple devices are supported with OS updates for around 7 years - for example, iOS 17 supports devices going back to the iPhone XR/XS (which were released in 2018). On the Mac OS side, things are a bit murkier, mainly due to current versions of Mac OS still supporting some Intel-based systems and ongoing uncertainty regardign the timeframe for dropping all Intel support. Assuming the 7-year window holds firm for Apple Silicon machines, even M1 would be supported through 2027, with M2 support dropping around 2029. There would be too much of a reputational (and likely financial) hit to Apple if they were to cut support for M1 and M2-based systems early.

Regarding the vulnerability itself, it would require certain cryptographic software to be running on the machine in question before the exploit could even be attempted because its that data which the exploit would try to pull from the prefetcher. Most users will never use those applications, so the risk would be minimal for them. There is another difference between exploits such as Spectre/Meltdown/Downfall and this one as well. Because this exploit relies on the DMP (data memory-dependent prefetcher) misreading data as a memory address, one possible mitigation measure would be to move those cryptographic processes to the efficiency cores (which do not use DMP). While there would be a performance hit like the Intel mitigations carried, it would still sidestep that vulnerability by forgoing the use of DMP for cryptographic operations. The existing M3 based Macs apparently do have a "kill bit" already which can be used to programmatically disable the prefetcher, so that could be easily ported into subsequent designs.

 

[CWallace]

What is the implication for security updates and long term support for an N3B Mac? Is it possible that security vulnerabilities may exist for N3B-based chip designs but not N3E/N3P-based ones? Is it costly (time and money) for Apple to continue supporting N3B for 6 or 7 years, despite the rest of the industry skipping N3B?

Apple supports the device, not the process node it was based on. So Apple will support devices built on N3B for the same seven-plus years they will for devices built on N3E once they move to it.

 

[JPack]

We know that Apple goes back to patch hardware vulnerabilities. In 2020, Apple went back to update N7-based chips even though Apple has just launched N5-based A14/M1.

Secure Enclave

The Secure Enclave is a dedicated secure subsystem in the latest versions of iPhone, iPad, Mac, Apple TV, Apple Watch, and HomePod.

support.apple.com

Apple is a proponent of security through obscurity, so we'll won't know what errata or vulnerabilities exist until after they've been fixed.

Will Apple update N3B chips just as they updated N7 chips in 2020? Who knows. I think much of it depends how how long of a tail end Apple expects from M3 products. If Apple still expects to be selling M3 MacBook Air in 2028, then probably a good chance Apple will make new masks for N3B designs.

 

[mr_roboto]

Or even better, an overhaul of the software model. We should finally accept that secure computing is not compatible with performance, and introduce "secure computing" modes that would disable speculative execution and other exploitable features of a CPU core.

Arm already introduced a feature for this in Arm v8.4-A, Data Independent Timing (DIT). A CPU switched into DIT mode makes these guarantees:

The architecture requires that:

• The timing of every load and store instruction is insensitive to the value of the data being loaded or stored.
• For certain data processing instructions, the instruction takes a time which is independent of:
  • The values of the data supplied in any of its registers.
  • The values of the NZCV flags.
• For certain data processing instructions, the response of the instruction to asynchronous exceptions does not vary based on:
  • The values of the data supplied in any of its registers.
  • The values of the NZCV flags.

DIT mode probably causes a big performance hit on many core designs, since it has to disable a lot of performance features, but that's typically acceptable since you switch it on to do small, significant things (e.g. public key cryptography to establish a secure channel) then switch it off for general purpose work.

The existing M3 based Macs apparently do have a "kill bit" already which can be used to programmatically disable the prefetcher, so that could be easily ported into subsequent designs.

In fact, the "kill bit" is just DIT mode. On M1 and M2, DIT mode doesn't disable the data memory dependent prefetcher (DMP), but on M3 it does. An oversight on Apple's part.

However, despite the big press craze about it being "unpatchable", Hector Martin has discovered that on M2 (and probably M1 as well, he just hasn't had a chance to check M1), there's an independent chicken bit for disabling DMP:

Hector Martin (@marcan@treehouse.systems)

Found the DMP disable chicken bit. it's `HID11_EL1<30>` (at least on M2). So yeah, as I predicted, GoFetch is entirely patchable. I'll write up a patch for Linux to hook it up as a CPU security bug workaround. (`HID4_EL1<4>` also works, but we have a name for that and it looks like a big...

social.treehouse.systems

Furthermore, Apple was already auto-disabling DMP outside of EL0 (the unprivileged user mode), so no DMP-based side channels can attack the kernel, it only works for user-mode processes. Quite a bit less doom than the sensationalist stories written about it tried to claim.

 

[leman]

Arm already introduced a feature for this in Arm v8.4-A, Data Independent Timing (DIT). A CPU switched into DIT mode makes these

That is interesting! Do you know if there are any intrinsics or APIs to set this mode in user code? I can’t seem to find good documentation on this.

 

[mr_roboto]

That is interesting! Do you know if there are any intrinsics or APIs to set this mode in user code? I can’t seem to find good documentation on this.

It's a process state bit, PSTATE.DIT, and it's exposed through a system register. See "Accessing DIT" here:

Documentation – Arm Developer

developer.arm.com

In C family languages, you can set it with a single inline assembly instruction.

 

[leman]

It's a process state bit, PSTATE.DIT, and it's exposed through a system register. See "Accessing DIT" here:

Documentation – Arm Developer

developer.arm.com

In C family languages, you can set it with a single inline assembly instruction.

Thank you! It would be great if there was an official API for this. That would also give the OS opportunity to tweak all the undocumented CPU-specific settings that could prevent side-channel attacks.