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.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.
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.
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.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.
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.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.
@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.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?
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
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.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.
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.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.
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.As is such new features are little more than promises without any commitment for actual products, like SVE and SVE2 have been for years.
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.
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.
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.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."
Remember when Nvidia left NEON out of some Tegra chips? That was a pain in the backside.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.
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.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.
Lol. Its not about planning...its about the SW will just crash.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 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?Lol. Its not about planning...its about the SW will just crash.
|Thread starter||Similar threads||Forum||Replies||Date|
|Question Snapdragon 8 Gen 2 announced||CPUs and Overclocking||53|
|G||Question Just saw that AMD announced that shipments dropped about 16% - will prices drop?||CPUs and Overclocking||65|
|S||News ARM Neoverse V2 and E2 announcements||CPUs and Overclocking||6|
|S||News ARM Cortex X3/Cortex A715 announcement||CPUs and Overclocking||26|
|J||Question Threadripper Pro 5000 announced||CPUs and Overclocking||43|