News [Anand] Arm Announces Armv9 Architecture: SVE2, Security, and the Next Decade

[Hitman928]

ARM has announced ARM v9. Anandtech article below.

Arm Announces Armv9 Architecture: SVE2, Security, and the Next Decade (anandtech.com)

 

[moinmoin]

😞

 

[moinmoin]

Hm, aside making SVE2 a part of ARM proper (yay!) the focus on security interest me the most, so I'm very disappointed how non-informative the announcement appears to have been in that regard. My hope is that it catches up to AMD's flexible approach to per instance/process memory encryption as well as I/O isolation, though the barebone slides shown don't really indicate any of that.

Looks like the NDA ended and CCA (Confidential Compute Architecture) is indeed comparable with AMD's SME and Intel's TME, but indeed doesn't come close to AMD's vastly superior SEV and isn't even an obligatory feature. That's a huge bummer.

ARM talks security, CCA, and Realms

Today ARM released some details about their CCA security architecture and Realms.

www.semiaccurate.com

Well if the box is compromised, what is to stop the bad guys from spinning up that same piece of malicious code in a Realm? At that point it is encrypted with the same key as the ‘protected’ data and can just read it like it wasn’t encrypted at all. This isn’t just a small problem, in SemiAccurate’s opinion it is a fatal flaw in CCA, it obviates the entire premise of protecting data. That said AMD’s SME and Intel’s TME have the same problem but they don’t make the claims ARM does.

Why is this a problem? If you read the marketing headlines, CCA should allow you to run secure VMs from your work for example without the device owner being able to see the sensitive data. As we mentioned before, if the device’s owner spins up an app to steal that data they get nothing. If they spin up an encrypted app to steal that data they get everything. Having one key per security zone, and only one key, essentially adds one very small step to the current process of data theft but won’t deter anyone competent enough to do it the old way for more than a few minutes.

So what can you do? This is where the underwhelming part comes in, as does AMD’s SEV. SEV stands for Secure Encrypted Virtualization but it doesn’t need to be used with virtualization. Like CCA it tags pages with a key, or more to the point what key to use, for encryption. Naples based Epycs support 254 keys, Rome and Milan have 510. In case you are wondering that is two per thread, 64C x 2T x 2S minus one for null and one for system, basically more than enough.

A system can encrypt each task, VM, or anything it wants to with a unique key under SEV. Any encrypted task that grabs data from another task gets garbage. If a VM spins up a malicious encrypted app, it is encrypted with a different key and gets nothing useful from it’s mining. This is the way to do things right, or at least the best we have at the moment, and CCA isn’t in the same league. Before you ask, Intel has nothing close, SGX is like a particularly malignant TrustZone with no benefits and lots of pain, it is a net negative for any system. CCA does encrypt data but doesn’t protect it in any meaningful or useful way, but it does do some good.

That is the first reason why SemiAccurate is down on CCA, it promises the world but delivers real but very limited gains. This would be OK but the second issue means these gains are going to be slow to spread and are unlikely to be ubiquitous in the market. Unlike AMD’s SEV which is available on 100% of their server CPUs, CCA is optional. Worse yet several key parts are implementation dependent so an OEM can chose to implement security or not. Without 100% availability, very few will write code that uses it so the added security will be the exception not the standard. ARM missed the boat by not mandating CCA.

 

[soresu]

Looks like the NDA ended and CCA (Confidential Compute Architecture) is indeed comparable with AMD's SME and Intel's TME, but indeed doesn't come close to AMD's vastly superior SEV and isn't even an obligatory feature. That's a huge bummer.

That makes sense, such features are not nearly as necessary in a client environment and they are still extremely likely to be in every Neoverse design going forward.

I wouldn't be surprised if they were already in N2.

Remember though that there is still that side project over security running that will feed back into the ARM ISA once it is finished - can't remember what it was called, just remember it had something to do with a UK university.

Ah found it, Morello/CHERI I think it was?

Mapping CHERI into Arm architecture

Looking at how to make computers fundamentally more secure, the University of Cambridge with DARPA created CHERI, making compartmentalization more efficient and scalable.

community.arm.com

 

[moinmoin]

That makes sense, such features are not nearly as necessary in a client environment and they are still extremely likely to be in every Neoverse design going forward.

I wouldn't be surprised if they were already in N2.

Lack of standardization means likely fragmentation with every custom design. Just make it some feature support levels and call them "Arm Client" and "Arm Server", "Arm Cloud", "Arm Pro" or whatever and ensure that the latter feature support level enforces the inclusion of everything. As is such new features are little more than promises without any commitment for actual products, like SVE and SVE2 have been for years.

Meanwhile AMD marches on from SME -> SEV -> SEV-ES -> SEV-SNP with all of them available on every Epyc Milan chip.

Remember though that there is still that side project over security running that will feed back into the ARM ISA once it is finished - can't remember what it was called, just remember it had something to do with a UK university.

Ah found it, Morello/CHERI I think it was?

Mapping CHERI into Arm architecture

Looking at how to make computers fundamentally more secure, the University of Cambridge with DARPA created CHERI, making compartmentalization more efficient and scalable.

community.arm.com

@Systems analyst mentioned it last year. And while promising indeed this is still in experimental academical state and only a possible extension for a future Arm ISA.

Department of Computer Science and Technology – CHERI: The Arm Morello Board

 

[Thala]

That makes sense, such features are not nearly as necessary in a client environment and they are still extremely likely to be in every Neoverse design going forward.

Of course ARM has to make this optional at architecture specification level - because, as you said correctly - it is not a feature every client implementation wants to have. Does AMD have SEV in every client product? I don't think so. So technically SEV is also optional in AMDs (internal) architecture specification and not mandatory for each product.
I am going to go out on a limb and say that this will be implemented 100% in all ARM servers but only a fraction of x86 servers - because it is not implemented in Intel systems.

Looks like the NDA ended and CCA (Confidential Compute Architecture) is indeed comparable with AMD's SME and Intel's TME, but indeed doesn't come close to AMD's vastly superior SEV and isn't even an obligatory feature. That's a huge bummer.

Thats not the case. SME and TME is protecting the whole memory only. CCA and SEV protecting on a per page basis - this is a huge difference. On the implementation side this means, that the page tables are tagged with cryptographic keys.
The main difference is, that SEV is supporting much more keys compared to CCA - and this is Charlies main gripe (aside from it being optional) - and even this is questionable as Charlie seems to deduce this just from slides...

ps: I tried to read up on CCA - but there is significant information missing in public information. In particular i do not see encryption mentioned at all in the public available documentation.

 

[soresu]

As is such new features are little more than promises without any commitment for actual products, like SVE and SVE2 have been for years.

SVE was designed alongside Fujitsu with a specific purpose in mind for the A64FX core used in the 'Post K' supercomputer (Fugaku?), and likely based on the academic paper for a possible post NEON extension named ARGON.

I don't think SVE1 was ever intended to become a mandatory part of the v8-A standard because lacking certain media/DSP instructions it was not a complete replacement for NEON in this earlier increment of the instruction set.

On its own SVE1 helped ARM get a foothold into the supercomputer business, and I think that carries a benefit all of its own without needing further use.

SVE2 on the other hand was designed as a complete functional replacement for NEON and superset of SVE with ARMv9-A in mind as it is now a mandatory requirement on the ground floor of first major ISA revision in 9 years.

IMHO they did not make it mandatory to a later increment of ARMv8-A because they did not want to clutter the standard.

Ergo actually delaying it to v9-A makes ARM ecosystem fragmentation less likely because SoC designers will switch to v9-A faster because of the benefits of SVE2 and other features make it a no brainer.

The mandatory requirement of SVE2 with v9-A is still only 2 years after it was announced in early 2019 - that delay is analogous to Intel pre announcing new instruction sets to allow compiler devs time to catch up.

 

[Thala]

I found all the presentation from the Linaro session including a panel session with security experts from Google and Microsoft (Azure) , who apparently contributed in the definition of the CCA architecture.

link

 

[Doug S]

SVE2 on the other hand was designed as a complete functional replacement for NEON and superset of SVE with ARMv9-A in mind as it is now a mandatory requirement on the ground floor of first major ISA revision in 9 years.

IMHO they did not make it mandatory to a later increment of ARMv8-A because they did not want to clutter the standard.

Ergo actually delaying it to v9-A makes ARM ecosystem fragmentation less likely because SoC designers will switch to v9-A faster because of the benefits of SVE2 and other features make it a no brainer.

The mandatory requirement of SVE2 with v9-A is still only 2 years after it was announced in early 2019 - that delay is analogous to Intel pre announcing new instruction sets to allow compiler devs time to catch up.

SVE2 is NOT a mandatory part of ARMv9, according to v9's release notes.

 

[soresu]

SVE2 is NOT a mandatory part of ARMv9, according to v9's release notes.

Regardless it's in every single one of the 3 new cores announced back in May including A510, and therefore pretty likely that it will be in every ARM Ltd v9-A core IP hereafter.

The likelihood of any custom v9-A cores not having it seems pretty low.

Though there is also a caveat to that document which actually dates back to March:

The information related to feature FEAT_RME is at Alpha quality. Alpha quality means that most major features of the specification are described in the manual, some features and details might be missing.

The information related to the remaining features is at Beta quality. Beta quality means that all major features of the specification are described, some details might be missing."

ie it's not impossible that they since changed that to mandatory for SVE2 and simply haven't updated it, though I'll grant you it's unlikely.

 

[NTMBK]

Regardless it's in every single one of the 3 new cores announced back in May including A510, and therefore pretty likely that it will be in every ARM Ltd v9-A core IP hereafter.

The likelihood of any custom v9-A cores not having it seems pretty low.

Though there is also a caveat to that document which actually dates back to March:

ie it's not impossible that they since changed that to mandatory for SVE2 and simply haven't updated it, though I'll grant you it's unlikely.

Remember when Nvidia left NEON out of some Tegra chips? That was a pain in the backside.

 

[soresu]

Remember when Nvidia left NEON out of some Tegra chips? That was a pain in the backside.

I don't, but then without Switch and their own SHIELD devices the Tegra line would have sank ages ago.

Was it the custom K1 chips with Denver1?

 

[Doug S]

Its certainly possible we'll see Apple do an ARMv9 SoC that doesn't include SVE2, if they decide to continue along their proprietary path with AMX. The way AMX is hidden with supported interfaces via libraries rather than compiler emitted instructions makes me wonder if it it was a stopgap/placeholder and they will eventually use SVE2 to implement AMX functions (once it supports everything AMX currently does)

All else being equal, it seems to me it would have made more sense for ARMv9 to include SVE2 as mandatory and make NEON optional and/or mark it deprecated to be removed in v10.

 

[NTMBK]

I don't, but then without Switch and their own SHIELD devices the Tegra line would have sank ages ago.

Was it the custom K1 chips with Denver1?

No, the Tegra 2. I think NEON was compulsory for ARMv8?

 

[Thala]

All else being equal, it seems to me it would have made more sense for ARMv9 to include SVE2 as mandatory and make NEON optional and/or mark it deprecated to be removed in v10.

Making NEON optional is a very bad idea. Current SW almost never checks for NEON, because it is assuming to be available. Future SW will certainly check for SVE2.

 

[Doug S]

Making NEON optional is a very bad idea. Current SW almost never checks for NEON, because it is assuming to be available. Future SW will certainly check for SVE2.

What "current software" is there for ARM where the end user is going to be running existing code and can select the ARM CPU themselves? I don't think that market exists, there are various self contained markets like Android phones, Apple phones, Chrome PCs and ARM Windows PCs where the OEM selects the SoC and is able to plan things like dropping 32 bit support. If the iPhone has apps that assume NEON for instance, Apple would support NEON for years until they are ready to obsolete those apps, just like they did for 32 bit (and like Google is now doing for 32 bit as well)

You have the server market where there is approximately no precompiled commercial software for sale so if you want to run something you have to compile it or download it from someone (i.e. Red Hat etc.) who does that for you.

You have the embedded market where the CPU and software are paired together by the manufacturer of whatever it is embedded in, and can select a core that supports NEON if they are using software that expects NEON to exist.

This isn't like the PC market where you couldn't drop say SSE3 because there are people running software that hasn't been updated for 15 years that assumes SSE3 support and need to be able to keep running that software for another 15 years even as the hardware changes because it is doing something like controlling a CT scanner.

ARM is in a position where legacy code is almost a non factor. It won't be that way forever - if they ever get any real traction on the desktop or in the datacenter and packaged software gets sold - and especially if an ARM PC becomes a peripheral to medical or industrial equipment the way x86 PCs have been for 30 years - then they will have to start caring.

Maybe that's the reason they made SVE2 optional - so you ALWAYS have to check for its existence and can never assume its there, allowing them to easily deprecate it someday when SVE3 is introduced.

 

[Thala]

What "current software" is there for ARM where the end user is going to be running existing code and can select the ARM CPU themselves? I don't think that market exists, there are various self contained markets like Android phones, Apple phones, Chrome PCs and ARM Windows PCs where the OEM selects the SoC and is able to plan things like dropping 32 bit support.

Lol. Its not about planning...its about the SW will just crash.

 

[Doug S]

Lol. Its not about planning...its about the SW will just crash.

If you try to run software that assumes NEON exists on a CPU that doesn't support NEON, yes of course it will crash. But how does this scenario occur? You aren't describing exactly how and in what ARM market it would happen. Embedded? Smartphones? Chromebooks? Servers? Where would this software come from that 1) assumed NEON 2) would never be recompiled/updated in the years after NEON became optional 3) continue to be used for so long that someone would someday copy it to a platform with a future CPU that had dropped NEON support and attempt to run it?

Software that uses AArch32 instructions will crash on an AArch64 only CPU. Yet Apple was able to make that transition, and Google is in the process of doing the same. How? PLANNING! They told developers years in advance that support for 32 bit apps would be dropped, stopped allowing app submissions with AArch32 code, and finally removed them from the app store entirely. Since I didn't have any 32 bit apps left on my phone when Apple made the cutover I'm not sure what they did there, I suppose either those were automatically removed when you updated to the first 64 bit only version of iOS (11? I think?) or you'd get some sort of error message if you tried to run one.

You don't think if NEON had been made optional in ARMv9 that the same sort of planning that allowed dropping AArch32 could be used to eventually drop NEON? Surely you agree that dropping the entire AArch32 architecture was a bigger deal, but Apple made it work and Google is on the path to doing so as well.

Your scenario doesn't hold water, because the ARM world is nothing like the x86 world. There are essentially no "dusty deck" ARM binaries that are going to be copied from old to new hardware repeatedly and assumed they will continue to work forever unchanged.