Slashdot Mirror

With subtitle "64/32 bit". See the "32 bit" part?

You do realize that means that the processor supports both 32- and 64-bit code, not that some are 32-bit only, right? "Most efficient 64-bit Armv8-A processor with full Armv7-A compatibility" in ARM's words.

Your argument still not supported, you are trying to parse a slide.

Sore because I can correctly parse one and you cannot?

How lame. See if you can find something better, good luck.

You surely realize that every ARMv8 processor short of the A76 is 64/32-bit, not 64 bit only. I mean, if you're comfortable with utterly gutting your own premise that "the power draw penalty outweighs the IPC increase, if there actually any" go ahead. The fact that the A35 (64/32-bit) is a higher efficiency core than the A32 (32 bit only) pretty much kills the argument even if you go that route.

My take on it: IPC differs only slightly between current 32 bit and 64 bit ARM cores, but power draw is significantly higher for 64 bit cores.

ARM disagrees (slide 7), but what do they know.

Is ARM the company a trustworthy enough reference about the Meldown variant they discovered in their Cortex-A75 core?

ARM cores with out-of-order execution are vulnerable to (regular) Spectre where as most ARM cores with in-order execution are not.
ARM posted a list of which that are affected. (But they use their own nomenclature...)

ARM Cortex-A53 and Cortex-A55 are the fastest 64-bit ARM cores without speculative execution, and yes, I think you'd want to choose 64-bit ARM (AArch64) for new applications.
Cortex-A53 is a bit old and most easily found in the Raspberry Pi 3 Model B and 3 Model B+ single-board computers, with four cores each. Both SBCs are cheap, widely available and have a lot of support. The Model B+ runs cooler and faster (1.4 GHz) than the Model B but both need heat sinks. If a heat sink is included at all in a kit it is often too small to be able to allow the chip to run at full speed for any length of time.

The Cortex-A55 is touted as being 20% faster than the A53 per clock. Most SoCs with the Cortex-A55 are running in a big.LITTLE configuration together with faster cores that run out-of-order.
I have found only one SoC with only A55: the Spreadtrum SC9863, which has eight cores at up to 1.6 GHz. It was announced in May and it is so early that I can't even find a datasheet for it.
Please do comment if you know of another option.

The referenced article: Vulnerability of Speculative Processors to Cache Timing Side-Channel Mechanism

Quote: "The majority of Arm processors are not impacted by any variation of this side-channel speculation mechanism. A definitive list of the small subset of Arm-designed processors that are susceptible can be found below."

Question: What processors are NOT vulnerable? The article lists only the processors that ARE vulnerable.

ARM Cortex A8, 9, 12, 15, 17, 57, 72, 73, 75... all of those implement speculative execution are are all vulnerable to Spectre v1 and v2. Some also v3, v3a and v4
The A76 is only vulnerable to v1 and v4
https://developer.arm.com/supp...

IBM Power CPUs do speculative execution. IBM aren't fixing Power 6 and earlier.
Power 7, 8 and 9 have been patched apparently (requires both firmware and OS updates to mitigate)

I'm sure there's more.

I thought AMD and ARM cpus were also susceptible to exploits. Is that wrong?

Indeed lots of different CPU manufacturer could be producing CPUs susceptible to spectre vulnerabilities.

But not all CPU are created equal.

There are some key differences :
  - not all CPUs actually do speculative execution. only a couple of ARM core actually do. The huge remaining amount doesn't and thus can't in any way be subjected to Spectre class vulnerabilities.

(Even some of Intel's own core, like some older Atom, or like Xeon Phi GPGPUs don't do speculative execution)

Intel has a different safety vs optimization threshold than most of others:

  - with most other CPU manufacturer, Spectre vulnerabilities boil down to "access memory region to which the process should already have had read access anyway" (see v1 and v4), thus it could be already addressed by safe practice (v1: don't put 3rd-provided JIT code and crucial information in the same process. e.g.: a browser's JIT engine running webpage's scripts and the password manager should not be in the same process) (v4: always clean up your stack before bailing out if it could contain cricital data, or better keep all the critical data in some specific mapped pages), etc.

  - Intel tends to push performance first to the detriment of anything else : some security test coming in too late.

AMD and most ARM won't speculate past memory protection. If a memory region is blocked from access for the process (generally : kernel memory), AMD will check the memory protection and never attempt to access the restricted region to begin with. Whereas Intel CPUs will speculatively access the restricted region and only do the check much latter, by which point the usual Spectre's cache loading side-channel leakage could have happened.
(There are few select ARM which are susceptible to Spectre v3a. Basically the same concept, but regarding system-reserved register - this being RISC architecture, with tons of registers)

AMD and ARM will honor non-maskable interrupt. In today's vulnerability Intel tries to speculatively execute the point past which the system should contect switch the FPU registers (which includes stuff like SSE and AVX registers. i.e.: an attacker could be speculatively peeking into what another process did with these - SIMD operations with SSE/AVX are used in encryption/decryption, so an attacker could occasionnally spot what other process are decrypting/encrypting and whith which keys)

So you end up with vulnerabilities v3 and today's which are Intel exclusive.

Also Intel tends to be a tiny bit more aggressive and/or jumping through some shortcut and/or having way deeper pipeline and longer speculations, in order to shave a few cycles off :
end results :
v2 (Indirect Branch prediction) is currently successfully exploitable on Intel. Though in theory some AMD CPU could do speculative indirect branching, there are no current usable exploits in the wild.
v1 actually works on Intel CPU without even activating the JIT - the speculation is so deep that an bytecode interpreter could speculatively access stuff
v4 works much easier on Intel (deeper pipeline higher chance to manage to read something that wasn't erased from memory yet)
etc.

TL;DR: due to technical choices prioritizing performance, Intel CPU tend to be even more vulnerable.

Well, pretty much all modern SIMD instructions are not RISC.

For specifics, here's an ARM document about instructions in the pipeline and how many cycles the different instructions are:
http://infocenter.arm.com/help...

RISC was supposed to be that any given instruction was simplistic and would use no more than a single cycle, and that the processing units would be utterly generic. Now we have something of a hybrid of that philosophy and CISC philosophy, with people 'rooting' for the relatively meaningless 'CISC v RISC' designations as they would their favored sports team.

From my blog:

Meltdown affects all Intel Processors with Out-of-Order-Execution (OOE) and, more importantly, Speculative-Execution, perhaps going back to the Original PentiumPro, and all Atom processors made after 2013 (the original Atoms were In-Order-Execution). AMD processors are immune [3], and Via (remember Via?) has remained silent. Meltdown also affects other architectures, like several ARM processors, including the up-and-coming Cortex-A75 (intended for datacenter use), as well as many others used in cellphones and appliances [5], also IBM’s POWER7+, 8 and 9 are affected [4]. But this paper is not concerned with other architectures.

[3] https://www.amd.com/en/corpora...
[4] https://www.ibm.com/blogs/psir...
[5] https://developer.arm.com/supp...

The Full Blog is here:
https://technologyunderbelly.b...

Hmm, I see what you mean about unaligned pointers and ARM. Support was added in ARMv6 and it's still there in ARMv8 AArch64 mode

AArch64
https://www.realworldtech.com/...

ARMv6
http://infocenter.arm.com/help...

Frankly if I were Microsoft and someone suggested adding support for non native kernel mode code I'd say "What an excellent idea. Why not suggest it to Dave Cutler, right now!". And then that would be last you'd see of them.

That's known with the quality of graphics rendering. With floating-point data, there's a technique known as guardband bits. These are extra bits of precision that remain internally within the floating point logic units. These aren't mandatory, but protect against numerical instability with small values. This can be visualized by comparing simple color gradients

https://community.arm.com/grap...

For some calculations like CFD, any overflow in one grid cell will expand outwards to all the other grid cells quite rapidly.

The Cortex-A75 is vulnerable according to ARM's own documentation.

In spite of it being perhaps more difficult to exploit, I have the impression that large data centres operating virtual private servers (commercial and corporate alike) have good reasons to be seriously concerned about Spectre.

Yes. Basically Spectre "Variant 2" / "Branch Target Injection" would allow to rent a VM on Amazon's cloud and spy on any other VM that runs on the same physical CPU.

“Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, {...} Wikipedia’s article on Meltdown says: “Meltdown attack cannot be used to break out of a virtual machine.” (Of course, Meltdown is nonetheless a critical problem, for other reasons.)

Meltdown / "Rogue Data Cache Load" specifically can access kernel (protected) memory.
It is something specific to Intel CPUs.

In order to make a few micro-improvement for speed, Intel CPU only check for protection at the last moment before committing the results to memory/register.
That means that speculative execution might get pas memory protection.

Your run a piece of software, your piece of software tries to read stuff from the kernel, the CPU does it speculatively, touches a few cache, and only then kicks the execution out. You can guess stuff by measuring which caches were touchs.

It works to get across the kernel/user-space boundaries. Gives you ability to peek into the kernel memory space.
It's madness that completely fucks up the base guaranties that memory protection is supposed to provide.

AMD CPU are confirmed to be not affected (they do the costly memory protection earlier and refuse to access protected memory).

Only a couple of ARM Cortex cores seem to be affected (basically only Cortex-A75 is affect in a way that is actually exploitable, according to ARM).

Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.

Please pay attention that there are 2 different Spectre attacks.

Spectre Variant 1 / "bounds check bypass" amd Spectre Variant 2 / "branch target injection"

The comment is only valid for the second one.

Variant 1 is just speculative execution working as it is supposed to do. If there's a condition (an "if" in the code) the predictor will try to guess which code path is the most likely to be taken, and speculatively execute that one. If the guess was wrong, the CPU throws the computation an restarts the correct branch. (but again, cache might have moved around and is something that is indirectly measurable).

If the condition is a boundary check, is might get skipped and CPU attempts to speculatively execute reads that are outside the bounds.
That's still reads to memory that should be accessible to the application anyway (meh). That would just cause the application to read one of it other's variable, instead of the array.
It's only a potentially exploitable situation when the application should not read it own data. Usually situations where arbitrary externally provided code reside in the same process as secret data. (And you basically deserve what you get for mixing sensitive data and arbitrary remote code in the same process).
Google example is done by sending eBFP a special type of bytecode used by modern packet-filters to the kernel. It's get jitted to machine code, and such code can read past its boundary speculatively.
Possible other exploit are sending specially crafted Javascript (there's a ASM.js demo floating on the web) or WASM, to a browser which JIT it and execute it. The code translate into a bound check, and could read any other part of the memory inside

Meltdown is also ARM, of their 10 Spectre susceptible designs, 4 are vulnerable to Meltdown or a variant of it they found.

Documented here - this is the only CPU listed by ARM as vulnerable to CVE-2017-5754.

ARM has reported that some of their processors are impacted.

The Cortex-A75 is supposedly vulnerable to all variants.

ARM has reported that some of their processors are impacted.

Yes, meltdown is an Intel only bug

So ARM is falsely claiming 4 of their processors are vulnerable to Meltdown so they can get some of that broken window action???

Meltdown exploits certain behaviour unique to Intel (and patented so that nobody else can use it).

I guess they'll be suing ARM any day now.

The Meltdown paper reports warning signs for AMD and ARM chip, but the researchers couldn't get a proof of concept to work (see section 6.4). As of the 3rd ARM has reported that 4 out of their 10 Spectre vulnerable designs are also vulnerable to Meltdown or a variant of it that they discovered.

Thank you for noting that you're not 100% sure it's right, and for the excellent summary. There's a ton of misinformation going around, especially with 0100010001010011 dude on Slashdot repeatedly posting that Meltdown is INTEL ONLY, which is false, as some ARM products are affected. What is true is that Meltdown does not affect AMD and affects only a few of ARM's processors.

As you state, it's important to rely on the original sources. Here is each CPU vendor's response to the security issues:
https://www.amd.com/en/corpora...
https://www.intel.com/content/...
https://developer.arm.com/supp...

Here are two corrections to make:
1) Meltdown:
One of your bold statements "AMD and ARM are not affected" is untrue. See here, from ARM directly:
https://developer.arm.com/supp...

ARM has confirmed that A75 is vulnerable to Meltdown. In addition, A15, A57, and A72 are vulnerable to a variant of Meltdown (Variant 3a) which ARM has added. ARM has stated that they believe this variant is NOT exploitable, however, there is already userspace code out there that can do some limited exploits:
https://github.com/lgeek/spec_...

AMD is not affected by Meltdown, in any form. From AMD's press release:
https://www.amd.com/en/corpora...

2) Variant 1: While other vendors may require application changes to address this issue, AMD appears to be able to address this with an OS update, based on their post:
https://www.amd.com/en/corpora...


Summary:
Variant 1: Some manufacturers (ARM) appear to not be able to fix it and are recommending compiler changes, but AMD will fix this in OS updates. Unclear how Intel is addressing this vulnerability.
Variant 2: Correct, from what I can tell.
Variant 3 (Meltdown): Affects nearly all Intel (within the last 10 years) and ARM A75 chips. AMD not affected.
Variant 3a (Modified Meltdown): Affects a larger set of high performance ARM chips

Finally, Intel has done a terrible job (intentionally?) at conflating the two issues, which is unfair. These are 3 separate security issues, with their own priorities and impacts. If you read Intel's official press release for this issue, there's no differentiation between variants 1-3, like there is for AMD and ARM:
https://www.intel.com/content/...

Thank you for noting that you're not 100% sure it's right, and for the excellent summary. There's a ton of misinformation going around, especially with 0100010001010011 dude on Slashdot repeatedly posting that Meltdown is INTEL ONLY, which is false, as some ARM products are affected. What is true is that Meltdown does not affect AMD and affects only a few of ARM's processors.

As you state, it's important to rely on the original sources. Here is each CPU vendor's response to the security issues:
https://www.amd.com/en/corpora...
https://www.intel.com/content/...
https://developer.arm.com/supp...

Here are two corrections to make:
1) Meltdown:
One of your bold statements "AMD and ARM are not affected" is untrue. See here, from ARM directly:
https://developer.arm.com/supp...

ARM has confirmed that A75 is vulnerable to Meltdown. In addition, A15, A57, and A72 are vulnerable to a variant of Meltdown (Variant 3a) which ARM has added. ARM has stated that they believe this variant is NOT exploitable, however, there is already userspace code out there that can do some limited exploits:
https://github.com/lgeek/spec_...

AMD is not affected by Meltdown, in any form. From AMD's press release:
https://www.amd.com/en/corpora...

2) Variant 1: While other vendors may require application changes to address this issue, AMD appears to be able to address this with an OS update, based on their post:
https://www.amd.com/en/corpora...


Summary:
Variant 1: Some manufacturers (ARM) appear to not be able to fix it and are recommending compiler changes, but AMD will fix this in OS updates. Unclear how Intel is addressing this vulnerability.
Variant 2: Correct, from what I can tell.
Variant 3 (Meltdown): Affects nearly all Intel (within the last 10 years) and ARM A75 chips. AMD not affected.
Variant 3a (Modified Meltdown): Affects a larger set of high performance ARM chips

Finally, Intel has done a terrible job (intentionally?) at conflating the two issues, which is unfair. These are 3 separate security issues, with their own priorities and impacts. If you read Intel's official press release for this issue, there's no differentiation between variants 1-3, like there is for AMD and ARM:
https://www.intel.com/content/...

ARM (and AMD) may be susceptible to the lesser of the two [evil] exploits... but the impact for that second one is considerably less than Meltdown (which is specific to Intel only).

That's incorrect. Per Apple's statement, all of Apple's ARM designs except the watch are vulnerable to meltdown. Also, the Cortex-A75 is vulnerable to meltdown. I agree that the initial PR spin from Intel was pretty ridiculous, but the good news is it looks like some engineers at Intel released a actual technical response. Reading through the whitepaper, it looks like Intel has figured out how to patch both meltdown and spectre on existing chips using a combination of microcode updates and OS updates.

Because ARM itself claims they are affected: https://developer.arm.com/supp...
AMD also claims one variant of the bug affects their CPU's: https://www.amd.com/en/corpora...

https://developer.arm.com/supp...

And also R7, R8, A8, A9, A17 and A73

Except that ARM doesn’t list the A7 or A53 as vulnerable.

https://developer.arm.com/supp...

So Eben knows just as much as ARM does.

No. The A-15, A-57, and A-72 are also vulnerable to a variant of Meltdown.
https://developer.arm.com/supp...

No. ARM has confirmed that Meltdown (i.e., Variant 3 and 3a) also affects some of their processors.
https://developer.arm.com/supp...

Please stop lying. You are a despicable liar.

You're the one who's wrong. ARM themselves note that Cortex A57, A72, A75 and A15 processors are affected by CVE-2017-5754 which is the Meltdown CVE (Spectre is CVE-2017-5753 and CVE-2017-5715)

Wrong. ARM has confirmed their Cortex A75 CPU is vulnerable to Meltdown (Variant 3). Please see their official statement here: https://developer.arm.com/supp...

WRONG. The Meltdown attack ONLY AFFECTS INTEL

False; Non-Intel platforms are affected by the same form of problems. The security issue related to Processor Speculation has been Acknowledged by ARM,
and furthermore, even the Meltdown paper points out the same issues existing with at least several example attacks working reliably on the ARM and AMD platforms regarding out-of-order executions And instructions past illegal memory accesses.

I think Cortex-A75

Here is some more. Now, where was my cheap, 12-core, high-frequency A55 processor for my almost embarrassingly parallel needs again, with SVE? What, no standardized open platforms available?

Perhaps ARM's press release detailing the ten affected ARM Cortex designs may convince you?

The Opteron-A is an ARM Cortex A57 design, and is vulnerable to three of the four variants of this bug.

ARM's own press release on the issue.

10 of the ARM Cortex designs are affected to some extent.

I managed to find ARM's press release.

As an aside, AMDâ(TM)s Opteron-A is Cortex-A57 design, which ARM explicitly states is vulnerable to 3 out of 4 variants of the bug in their press release. Iâ(TM)ve heard Google's Project Zero released more details too (sorry, no link, I haven't read it yet).

Intel is still being a weasel in their press release, of course.

How about ARMâ(TM)s own How about ARMâ(TM)s own press release and white paper?

For the record, AMDâ(TM)s Opteron-A is a Cortex A57 design, which is affected.

https://developer.arm.com/supp...

Read ARMâ(TM)s own statement.

They list four variants of vulnerability, and includes the following ARM cortex designs:

* R7
* R8
* A8
* A9
* A15
* A17
* A57 (Includes AMDâ(TM)s Opteron-A)
* A72
* A73
* A75

So go look at ARMâ(TM)s document, and read their white paper. As ARM claims many of their designs have this bug, Iâ(TM)m inclined to believe them.

ARM has released their own statement

While stressing that it doesnâ(TM)t affect all of their cores, the list of cores affected to at least some extent is not small.

Bullshit? Look at the table in this from ARM listing all the affected ARM architecture processors from ARM.

This chip has a built-in hardware HEVC decoder (and encoder).

Dude, nowhere in that article does it indicate that the A8 has a fixed function H.265 decoder. They don't even mention HEVC or H.265. If you follow the links in the article you'll see that the 4K video demo is for 4K H.264 video, not H.265.

By the way, GPU acceleration implies GPU computing (OpenCL, CUDA, Metal, etc.).

Yes, that's right. It sounds like that's what Apple's doing. The A8 has a PowerVR GX6450 which supports OpenCL. I wouldn't be surprised if they're using Ittiam's GPU accelerated H.265 codec. Apple could support GPU accelerated VP9 and AV1 decoding just as easily.

This seems to be a patent on using hardware virtualization in sandboxing. In a 5 minute search, I found a couple of references to prior art, though it seems if Google's lawyers couldn't get this struck down, there may be something novel hidden in there somewhere.

With its 2011 copyright date, that ARM document appears to be 6 years too late to be prior art.

Claim 15 of https://www.google.com/patents/US20060031940 seems pretty descriptive and was filed in 2004.

This seems to be a patent on using hardware virtualization in sandboxing. In a 5 minute search, I found a couple of references to prior art, though it seems if Google's lawyers couldn't get this struck down, there may be something novel hidden in there somewhere.

>In computers, "random number generators" are often only pseudo-random, and are in fact deterministic.

Unless they are the ones commonly found in every modern CPU, which include an entropy source.
E.G:
Intel : http://www.rambus.com/wp-conte...
VIA : http://www.rambus.com/wp-conte...
Many Arm Socs: https://community.arm.com/mana...

-1, misinformative

RISC-V is an ISA only. It does not oblige implementations to follow any particular microarchitecture.

The religious wars between CISC and RISC were given up decades ago in favor of data-driven architectural decisions. If using sequenced uops solves the problem, they'll be used. For example, here the Cortex-A57 Software Optimization Guide explicitly refers to uops starting in section 2.1: http://infocenter.arm.com/help...

In the future there won't be any CISC or RISC, just wankers.

She doesn't have a maths degree, so it must be really difficult for her to understand all profits now will no longer boost UK GDP, but instead boost Japan's GDP

I don't think you have an economics degree.

If a multinational produces income in the UK, it is counted in UK GDP statistics regardless of country of ownership. If profits from that production is exported back to another country, those profits are subtracted from GNP, not GDP.

I don't know where ARM licenses are billed to, but they have operations all over the world, and "Management periodically evaluates individual positions taken in tax returns with respect to situations in which applicable tax regulation is subject to interpretation and establishes provisions where appropriate on the basis of amounts expected to be paid to the tax authorities" (i.e. they shop for the jurisdiction with the lowest corporate tax rate to recognize income where they can get away with it).

Moreover, "The benefit of UK research and development is recognized under the UK's Research and Development Expenditure Credit (RDEC) scheme" and "In 2013, a decision to elect into the UK patent box regime was made. The UK patent box regime seeks to tax all profits attributable to patented technology at a reduced rate of 10%." (source).

You would need a USB stick that implemented a secondary device to uniquely identify the USB stick to avoid piracy. Implementing something like ARM TrustZone in a USB secondary function device would seem to suit this purpose nicely. Games downloaded to your USB stick could then only be used when that particular USB stick is physically present on your gaming system.

It's not really true. What's true is that there is no working OSS driver for Mali. PoC has been done (ISTR Quake 3 running) but there's nothing you could actually count on. Most of the driver is closed-source, and provided by ARM only to Mali licensors. The wrapper bits are open source.

It's also true that more effort is put into Android video support than Linux support because the majority of the Mali customers are running Android.

The advent of the Internet of Things, with billions of additional connected devices offers significant enhancements to how we live our lives as citizens but also carries risks around subversion of the technology and management of privacy. With this in mind ARM is working with its ecosystem to develop advanced system platforms that integrate robust security controls that can ensure data is tightly constrained.

REF: Internet of Things & Embedded Security

How so? ARM processors are quite plentiful and support several operating systems already. Perhaps you're just not very familiar with them. Not to worry. There's plenty of material available.

I've designed embedded computers and written boot rom code and ported kernels to arm and other processors. While arm has a more intelligent design to it than an x86 its still far behind other processors with its 16 registers (MIPS,PowerPC,etc have 32 plus a few dedicated ones). It also lacks in the fact that it must have its address space split in half to support I/O. The only thing arm does well is conserve power.