22 ms·
x86 finds its way into the iPhone
- chrisfosterelli 8y agoCan someone explain why it's a big deal they are using an x86 chip? It seems ARM is the standard in the mobile world, but I'm not sure what the motivations might have been for the change or if this has drawbacks that make it so surprising.
- jannes 8y agoI was under the impression that x86 is not energy-efficient enough to be used on a phone. But I guess that applies to the modern variant of x86 with a quite bloated instruction set. Who knows if this version of x86 has a more restricted instruction set.
- umanwizard 8y agoWhat is the relationship between the instruction set and the power efficiency?
- ZirconiumX 8y agoA more complex instruction set needs more silicon to decode, and thus is less power efficient. However, I'd imagine that Intel are pretty good at decoding x86 at this point; they've had plenty of practice, so it might balance out.
- flamedoge 8y agoyes, but usually complex = variable length encoding. size is also a factor.
- astrodust 8y agoA 7nm process Pentium III is going to use almost no power and take up very little space. An 80486 would be even tinier.
- tracker1 8y agoCould even be a modernized 386 with cache and integrated co, effectively a 486dx without all the additional instruction support.
- Symmetry 8y agoIt depends on the regime you're operating in. In a processor that's superscalar but in order the higher cost of decoding two x86 instructions versus decoding two ARM instructions is actually significant. But if you're reading instructions in at one or two bytes per clock tick x86's more complicated instructions make a lot of sense since they save on instruction stream size. And if you're dealing with a modern wide issue out of order machine the decoding costs are just lost in the noise. EDIT: Oh, and load-op-store instructions make the level below superscalar a bit harder to design at least. And x86's strong versus ARM's weak memory ordering guarantee have effects even in OoO-land though which one is better is a very complicated issue I'm not going to try venturing an opinion on.
- monocasa 8y agoThere's give and take here. Instruction set density is correlated with variable length instructions (which makes sense from an information theory sorta huffman encoding perspective). Even most modern RISC instruction sets designed for code density are variable length (looking at Thumb2 and RISC-V C here). So your choices are either you pay the power cost on the increased I$ size, you pay it on the decoder, or you take a hit on perf.
- klodolph 8y agoPeople like to get in hot fights about this all the time, and I could be taking the bait, but there is an overhead to instruction decoding and fetching that changes with the complexity of the encoding, and there is also a cost of implementing all the instructions. Simpler instruction set means fewer gates means less power draw, with some hand waving. The ARM 1 had 25,000 transistors and the ARM 2 had 30,000. The contemporaneous Intel 386 had 280,000 and the 486 had 1,200,000. Intel had the engineering resources to design powerful chips that people bought in droves, ARM had a very small number of engineers and had to design something smaller but as a consequence the ended up with very low power consumption, which wasn’t important until people put it in phones. Since then Intel has optimized for power consumption but they were catching up for a long time. In most modern CPUs, other factors dominate and instruction set is less important. Nowadays we have plenty of gates to spare and the question is how much can you accomplish at a given price and power envelope. And it’s irrelevant to talk about power consumption of a baseband processor unless you’re also talking about the power consumption of the radio, since they get used together.
- minipci1321 8y ago"Empirical Study of Power Consumption of x86-64 Instruction Decoder" https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool... From the conclusion: "The result demonstrates that the decoders consume between 3% and 10% of the total processor package power in our benchmarks. The power consumed by the decoders is small compared with other components such as the L2 cache, which consumed 22% of package power in benchmark #1. We conclude that switching to a different instruction set would save only a small amount of power since the instruction decoder cannot be eliminated completely in modern processors."
- klodolph 8y agoYep, that pretty's pretty much it. Back in 1985 when the 386 and ARM 1 came out, neither had any cache at all. But I think the paper is a bit narrow in scope, relative to the discussion here. For any given application, you want to find a cheap part that can run that application. If you can run the application on an 8051 with a few K of ROM, then you can save a lot of money and reduce power consumption by switching to the 8051. If you need a powerful DSP to do some SDR for your cell phone radio, you're going to pick a different instruction set and pick a part that draws a lot more power. I think the paper is taking as fixed the part functionality and considering how the encoding can be changed, but for a core running code that is not user accessible, the engineers are free to choose a core with functionality that suits their particular needs (which you can't do with the main CPU). What's surprising to some people is that Intel has successfully scaled down their x86 cores so you can use them as embedded cores in larger ASICs, essentially. You can reuse a successful core design like the Pentium 4 and adapt it to a modern 14nm or 10nm process and you end up with something cheap and easy to use. 10 years ago that wouldn't have worked. Even recently it was much more common to use dedicated DSPs everywhere, but these days I feel like people are ditching the DSPs for cheap and ubiquitous general purpose CPUs and microcontrollers.
- bitwize 8y agoIt's probably something like a Quark, which is basically a Pentium SoC that can leverage modern manufacturing techniques to get the die size and power consumption down.
- kevin_thibedeau 8y agoCortex family chips take compressed Thumb instructions and translate them into ARM. PentiumPro and up does roughly the same with x86 -> uOps. There is no telling what the internal instruction representation is on these parts and how CISCy it actually is. Though Intel have been using updated low power 486 cores as microcontrollers for the past few years it could just as readily be Atom.
- awalton 8y agoThe Quarks (rip) had a reduced and improved x86-compatible instruction set and they were quite low powered... they really failed to catch on because Intel didn't think to put them in a friendly package to be integrated into anything - they thought teeny tiny pitch BGA was fine for the Maker community that still loves their throughhole components. (And they were kinda buggy chips, but they had roughly shaken them down well by the next silicon spins). I had kinda hoped the Quark would stick around, just so Intel could start sundowning some of those terrible old instructions and execution modes and start properly decrufting x86 - it's 2018, we don't need 32-bit Real Mode anymore, we can emulate it a thousand times on a PC and still have processor power left to play video games. But, that being said, these things probably have a "Mobile Core" processor (i.e. an Atom), which are quite low powered still, and they probably don't run them at all that high of a clock rate either, saving more power.
- chx 8y agoThis is just baseband. It doesn't need an Atom, hell no. It could be like a 486 core manufactured on a ten year old process and it'd still be ridiculously overpowered for the task. More likely it's a P5 core because Intel have repeatedly used that core to produce things -- Bonnell and Larrabee. Anyways it probably runs at like 100 MHz or such and consumes a few tenth of a watt. Maybe an ARM consumes less but compared to the main CPU it's negligible anyways.
- ksec 8y ago>It could be like a 486 core manufactured on a ten year old process and it'd still be ridiculously overpowered for the task. I think you have vastly underestimate the amount of processing power required for modern days 4G LTE computation requirement. Even with an Modern DSP.
- nimish 8y agoIntel is obviously going to use the x86 core they own so they don't have to pay license fees for embedded ARM cores
- uluyol 8y agoI believe that all of Intel's mobile networking products were purchased from infineon. So it wouldn't be surprising if they used ARM until now given that it takes time for these things to change. They even manufactured these chips at TSMC for a while.
- detaro 8y agoIntel is a pretty large ARM customer, so them using ARM here wouldn't be that surprising either.
- vl 8y agoRemember when Intel sold StrongARM division? :)
- btian 8y agoIs that the same as XScale, or something else?
- gsnedders 8y agoI presume they mean so; they bought StrongARM, later replaced it with Intel designed IP (marketed as XScale), and sold on that team. I don't actually know that the StrongARM team and the XScale team are one and the same.
- gip 8y agoThey were - I was on that team. StrongARM came to Intel when it acquired DEC. The CPU was developed thanks to an 'architecture license' from ARM. Intel renamed the processor XScale and later sold it to focus on embedded x86. https://en.wikipedia.org/wiki/StrongARM https://en.wikipedia.org/wiki/StrongARM
- deleted 8y ago[deleted]
- monocasa 8y agoThere isn't a big deal. Hell, AArch32 has something like 1400 instructions, it's just as complicated as an embedded x86. And as someone who's ported a kernel to both, it has just as many weird parts of the architecture built up over decades (ARM is about as old as 32 bit x86). The motivation for the change is that Intel's making the baseband instead of Qualcomm now, so it's not an ARM/Hexagon like it once was. The author is just bent around a decade plus out of date view of chip architecture.
- jonstokes 8y agoThis ^^. The "OMG... HORROR" in this article about the mere fact of x86 usage is deeply silly. The stuff about C64 and so on at the end... there's just no redeeming this mess. The mods should nuke it.
- monocasa 8y agoSo, I just want to throw out there that your arstechnica uarch articles are one of the things that pushed me into computer engineering rather than straight CS. And Inside The Machine I consider to be up there with Patterson & Hennessy. Thanks for all of that! : )
- jonstokes 8y agoThanks!
- evancox100 8y agoHey, same here! Your articles are what inspired me to go into chip design /computer engineering. Still have my signed copy of Inside the Machine on my bookshelf :) Thanks a ton!
- godelmachine 8y agoThanks for the info! Now there's a pundit I can follow and read the books he authored.
- 8y ago
- sempron64 8y agox86 is considered a much more complex instruction set than arm, with multitudes more side-effects. This makes baseband firmware exploits potentially more likely. That said, modern ARM architectures are also quite complex and calling them RISC is a stretch.
- Symmetry 8y agoThere isn't anything to really indicate that this processor has many more instructions than a 8086, befitting its role as an embedded device. I'm not aware of any difference in x86 and ARM semantics in embedded that might cause a problem. Now, the fact that an x86 instruction stream isn't self-synchronizing can represent a danger in theory. That is, you can craft a sequence of x86 instruction such that if you start executing form 0x0000 they're safe and friendly but if you start executing from 0x0001 you'll see a different, equally valid, stream of instructions that might do something malicious. But that doesn't seem like a credible attack vector in this case given the embedded nature of the code.
- monocasa 8y agoI'll throw out there that unaligned, unintended instructions can give an attacker more options from an ROP perspective. But it's only a small benefit for the attacker. And for something like this 30MB binary it's six of one, half dozen of another practically speaking.
- dfox 8y agoWell, the disassembly in the article contains LGDT, so it is certainly significantly more complex core than 8086.
- stefan_ 8y agoThere was no change. Presumably Intel always used a x86 CPU for their baseband, because they own all the patents on that stuff so they don't need to pay any royalty on it. Chances are this isn't even a true x86 CPU, just some ad-hoc smaller version of it. Wonder what cpuid returns on it :)
- heisenbergs 8y agounlikely. intel's baseband originates from infineon which intel bought a couple of years back. Hence it probably was a pure ARM baseband until intel purchased them and insisted on using x86 cores?! very weird move, particularly as i'd assume it also still has ARM cores in the baseband, making it a mix of x86/ARM cores.
- stefan_ 8y agoA lot of the acquired expertise is just the analog stuff, which obviously doesn't care what the processor is very much. If you're shipping one of the highest-dollar chips in the iPhone, I'm sure cutting out ARM is one of the juiciest moves possible. That would have been a very big target for them.
- anticensor 8y agoIllegal instruction exception, then randomly mocking the instruction stream?
- MBCook 8y agoMy guess is simply that Intel has wanted to be on the iPhone for a long time instead of ARM and, in a very tiny way, it’s finally happened. Just an interesting find/factoid more than anything earth shattering or important.
- sounds 8y agoWell, just for one: Spectre affects almost all CPUs. It affects ARM CPUs. But Meltdown only affects x86 CPUs. [1] [1] https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability) https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili... Maybe Intel used such an old core design in their baseband that it's not affected? Nah, that'd just be too good to be true.
- zamadatix 8y agoYour source that Meltdown only afects x86 CPUs literally starts with "Meltdown is a hardware vulnerability affecting Intel x86 microprocessors, IBM POWER processors, and some ARM-based microprocessors.[1][2][3]" and that iOS needed to be patched. Also worth noting AMD x86 CPUs were not affected. Meltdown was definitely more a "how good was your implementation" question not a "are you x86" question.
- agency 8y agoCan you describe a situation where an adversary would be able to run user code on a phone's baseband processor? This is a serious question - I don't know anything about smartphones. Do apps have access to the baseband processor? As an uninformed bystander I would think not...
- atq2119 8y agoIt might be possible to find and exploit a buffer overflow by impersonating a cell phone tower. Not exactly trivial to pull off, but certainly not a priori impossible.
- acoye 8y agoThis comment is down-voted as other archs are vulnerable to Spectre/Meltdown not just x86. True. Yet, as of right now Intel as not fixed in silicon all spectre/meltdown issues. Given the R&D / QA time on a specific arch, I'd bet it is still hardware flawed if they took an of the shelf in house x86 design. Atom based maybe? So I do not feel confident for a chip that runs the broadband and moreover one that is not auditable by the end user (unlike a main CPU would be). I would be supper interested in knowing if the reverse engineering show traces of retpolines.
- deleted 8y ago[deleted]
- bitwize 8y agoBecause x86 is symbolic of the peecee world, which Apple supposedly historically opposed. Beyond that, Apple fans seem to get a raging hardon from Cupertino gaining more and more control of every aspect of the supply chain, from silicon to bits to services, and Apple still depending on third parties for their baseband -- let alone Intel, of the dread Wintel alliance -- just seems so... tacky. Besides, it's CISC, and everybody knows RISC architecture is going to change everything.
- draw_down 8y agoCome on. Every Mac available for almost 15 years now runs on Intel x86 arch
- detaro 8y agoIt's IMHO not a big deal, but still interesting. Intel has seemingly invested less and less into their small embedded stuff in the past few years, is known to use ARM in various parts, so it's interesting to see that they've made this switch here and are using their embedded developments in their integrated products.
- tracker1 8y agoDefinitely interesting.. I mean a 486dx class processor with modern mfg, bigger cache and higher clocks than in the late 80's would totally sip power and be very capable... even the p2/3 designs could work well in a lot of embedded scenarios.
- omarforgotpwd 8y agoIt's not a big deal, you just wouldn't expect that your iPhone is running x86 instructions.
- mankash666 8y agoMuch Ado about nothing - Intel furnished modem on the iPhone uses x86 instructions!!!
- danmg 8y agoWell it's a battery powered phone. Decoding x86 instructions and converting them to the processor's internal microcode, unless it's not really the full x86 ISA, is not energy efficient. This means there may be a noticeable battery life difference between the GSM and CDMA versions of the new iPhone.
- monocasa 8y agoThose benefits are really over stated. Even the slightly bigger RISCs will convert into internal micro-op for various reasons generally. You can even see this openly in the RISC-V BOOM HDL.
- mankash666 8y agoWait what. Where is this article suggesting conversion of x86 to arm assembly prior to execution? Stop making things up. Unless otherwise proven, it's x86 executable running on x86 intel cores within the modem or related compute.
- monocasa 8y agoI don't read anything of the sort in his comment.
- mankash666 8y agoThen you don't read right. "Decoding x86 instructions and converting them to the processor's internal microcode ..."
- danmg 8y agoModern x86, for the past 25 years or so, doesn't implement the instructions directly. There's an internal intermediate, proprietary reduced instruction set. So outwardly it's a cisc processor, with variable length instructions and a lot of different instruction modes, but internally it's not.
- sigmaprimus 8y agoCould this is a preeminent move to produce more parts in the US by Apple to avoid the new tariffs being imposed? How many years of R&D are required before production of a new phone these days? I hope this change will result in new low price SoC board PCs running x86 cores to compete with RPIs entering the market soon.
- klodolph 8y agoI suspect the new baseband processors are powerful enough that you can use one part for everything, rather than a different baseband processor depending on your network, which makes things cheaper. Tariffs might be a factor but Qualcomm works with Global Foundries which has fabs both in the US and elsewhere.
- deleted 8y ago[deleted]
- devy 8y agoSince Qualcomm and Intel are the baseband/modems manufacturers and Apple has little or may not have anything to do with developing these x86 baseband modules, this should be mostly Intel/Qualcomm responsibility to tighten up the security, no? It's like we can't fault Boeing for the plan crashes if it's a CFM56 engine failure, right?
- pantulis 8y agoI'm buying the product from Apple. If some of their suppliers screw up, I'm blaming Apple, not Intel or Qualcomm.
- aij 8y agoI don't think the CFM56 is a good analogy here. It does not appear to have been designed to fit the bolt pattern of a Cesna 172. The main thing the x86 instruction set has going for it, is backwards compatibility. (Including the fact that there are a lot of highly optimized CPU designs around that instruction set.)
- kolderman 8y agoBut what core? Intel Atom? And does this mean it can run Doom?
- Symmetry 8y agoCertainly not as big as an Atom, that would be an application core. Possibly a Quark[1] or possibly something custom cut down even further. [1]https://en.wikipedia.org/wiki/Intel_Quark https://en.wikipedia.org/wiki/Intel_Quark
- pq0ak2nnd 8y agoCan someone recommend a good resource to analyze entropy in a file as the author discussed?
- zeeboo 8y agoThe easy way: compress it with whatever you want (xz? gzip?) and compare the sizes. If it doesn't get significantly smaller, it's probably encrypted or already compressed.
- danmg 8y agobinwalk -E Will show a graph of the file offset vs shannon entropy.
- lcq2 8y agoread "A Mathematical Theory Of Communication" by Shannon himself, it's the only source you will ever need, it's available for free
- johnvega 8y agoI did lots of coding for x86 assembly in college, so this article was interesting. Actually, it was fun reading it.
- gip 8y agoI was working as a Postdoc at Intel around 2005 when they decided to sell their X-Scale business (the ARM CPU they got when they bought DEC). My manager said that embedded x86 will make its way into smart phones. It was a long long shot back then. I admire folks at Intel for their persistence!
- dfox 8y agoOne thing that strikes me as highly weird is x86 code in ARM ELFs. It is usually the other way: code for some random embedded custom almost-RISC in ELFs claiming to be for i386 :)
- lcq2 8y agothey're not standard ELF files, more likely they're using the ELF format just to have a list of "load address-size-data" stuff assembled with some custom linker script, and they did not bother to change it, probably because of integrity checks or sanity checks along the assembly line would have been much more fun if they switched to PE format though, like they did with EFI/UEFI :D
- bogomipz 8y ago>"What I discovered sent a shiver of horror down my spine", "I couldn't believe my eyes", "Holy shit" These seems like a lot of histrionics for a summary that reads: >"Conclusions Nothing really, I just found this funny and wanted to share."
- bowyakka 8y agoSo while I am sure the author checked this, it bears mentioning that disassembling CISC is more of a black art than RISC. You can feed any binary file into a disassembler and get x86 code out, even if that code is invalid. For example here is a "program" except it's really a meme gif off my phone. https://imgur.com/gallery/hoDKeC9 https://imgur.com/gallery/hoDKeC9
- monocasa 8y agoYeah, but it's really clear that his stuff is real x86. lgdt followed by setting up all the data segment registers followed by a long jump to the code segment is about as x86 as you can get.
- umanwizard 8y agoAre you experienced with reading x86 assembly? It's crystal clear that the gif from your phone is gibberish (or extremely obfuscated), whereas the code from the article is normal-looking.
- bowyakka 8y agoI am, I am not faulting the original author just pointing out you can get disassemblers to come up with x86. From the comment right under the picture I took > yeah, pretty typical function prolog, what's the question ? Except we know it is not. I am more saying to people be careful pushing any old binary blob through capstone without considering what it might produce, I get this at $DAYJOB where people disassemble VAX from things that are just data.
- tebruno99 8y agoIn the closed box that this chip is in, as long as it meets power usage spec then it doesn't really matter what Arch it is. Not sure what the big deal here is other than some personal bias the author has against x86
- nickpsecurity 8y agoThey’ve been in embedded with Atom processors for a while. VIA/Centaur beat them to it with C3, etc.. Id have assumed Intel would be in a mobile eventually if they weren't already. Wonder why x86 is that surprising. Also, early Nokia 9000 Communicator had x86 CPU. I think it was a 386. Mobile returning to x86 instead of going to x86.
- grawprog 8y agoArm scares me far more than Intel or Amd. The way they license their chip designs is what's created the fragmented mobile ecosystem we have today. I remember watching an interview a while back about arm chip technology with someone from their company about how their revolutionary virtualization technology could be used to run any OS on their chip...then the spokes person laughed and said how this would never happen and would insted be used by licensees to lockdown their processers even further. I'm really not a big fan of ARM or the company in general. Intel does some shady things but arm is a whole different beast altogether. It's designed with arbitrary software lockouts in mind and their licensing scheme is not conducive to open development.
- userbinator 8y agoThe author may have let his preconceptions get in the way of reasoning a bit too much --- x86, or at least x86 compiler output, is easy to recognise in hex/ASCII mostly because you'll see things like function prologue/epilogue sequences (55 8B EC, 8B E5 5D C3) and NOP (90) or INT3 (CC) padding everywhere. ARM, MIPS, and Z80 (the other 3 I can recognise by sight) all have their distinct "textures" too. this is awesome… I'll be the first to comment on the apparently misplaced bounds check(!) in the fragment of code above it; it reads a parameter from the stack, compares it with 8A, then makes it an index into some array of 8-byte elements and reads the two values from memory before deciding whether it's valid or not --- and seems to put -1 into eax if it's not. Not really a problem if this is running in realmode (or "unreal mode") with no memory protection (it will just read 8 bytes from somewhere in the address space, and probably ignore them), but it could crash if it was in protmode (which the lgdt in the preceding fragment suggests) set up with restrictive segment liits, and the memory address was not valid. Then again, the check could be completely superfluous if that function would never be called with an out-of-bounds value...
- yalok 8y agoI wonder if the Dual SIM Dual Standby feature has anything to do with this, even as one of the minor reasons to switch to x86. Even though standby mode itself is usually the least demanding, and so it will just mean doubling of memory... Seems very unlikely, but from product perspective it’s one (and maybe only) of the new features that’s related to baseband.
- spyridonas 8y agoThey also added 5g as well.
- jsjohnst 8y agoDoubtful, as Qualcomm baseband chipsets have been in dual sim phones for ages. It’s more likely two reasons: 1) Intel somehow is doing CDMA now, that’s a major reason previous generations were split between Qualcomm and Intel 2) The major reason Intel has a seat at the table is due to Apple and Qualcomm‘s very public fight. Intel and Apple don’t have an entirely happy relationship, but it’s a far better relationship than Apple and Qualcomm
- ksec 8y agoThis is the first time Intel is the sole baseband modem supplier for Apple's new iPhone. This is also the first time Intel has their baseband modem manufacture in their own 14nm Fab. This is also the first time any Intel modem had support for CDMA / TDS-CDMA. This is also the first time Intel made x86 into their baseband modem. All previous modem, 8 years since Infineon has been sold to Intel, has all been ARM based. So yes, lots of hope for this new Modem. And finger crossed Intel don't mess this up.
- jsjohnst 8y agoAnyone know if it’s the Intel XMM 7560? Very likely based on specs mentioned at the keynote, but won’t know for sure until the tear down next week I guess.
- lcq2 8y agoyes that's the model "ICE7560_XMM7560_RFDEV_UB_FLASHLESS" :)
- jsjohnst 8y agoReading the spec sheet on it has me feeling in awe for the antenna designer. This chipset claims to be able to simultaneously tune in on 850 / 900 / 1500 / 1700 / 1800 / 1900 / 2200 / 2800 / 3500 / 5000mhz. Having gone through the “black art” of antenna design just for a few of those frequencies before, I can’t imagine trying to cover all of them well, but I also know if anyone does it well, it’s XX’s team (not outing the person as I don’t know if it’s well known who leads that team at Apple).
- Mauricio_ 8y agoUntil 2015 my phone was A Motorola Razr i, which used an Intel cpu with x86 architecture, so it's not that uncommon. Also the PS4 uses today x86 for its main cpu. It's not mobile, but comparing it to Z80 is exaggerating a bit.