The reasoning by Daikin is a load of nonsense.
Freescale ARM and Power products are the only mass market processors and controllers available with tamper detect, secure boot, flips 140-3 grade security and in certain products side channel analysis production. maxim and a few others make parts but no support across the entire range.
I just finished design of a tablet ref design for mil grade security and only the Freescale I.mx6 cut it. granted the Mcafee stack helps but security 101 says that the root of trust begins in hw. Add to all this arm's Trustzone really hels secure os partitioning.
In summary, it looks to be a poor technical decision.
Note, am not a Freescale employee or contractor. just a security researcher .
At the core level most stacks are the same but the McAfee stack in recent years is probably one of the most comprehensive in terms of publicly listed features. I build my own stacks (like a secure android variant we are building right now) so do not end up doing detailed competitive analysis.
But no publicly available stack has a cohesive published security architecture. Makes me nervous since I cannot do a vulnerability analysis ! literature tends to focus on bells and whistles.
But all f this is missing the wood for the trees. Security engineering is an exercise in futility unless you have a proper trust chain starting with secure boot. You need cryptographically secured boot loaders and kernels for starters. At least for systems used in critical infrastructure.
On top of the hw you need an os designed for this millennia, not the various variants we have that derive their inspiration from the 70s. curiously enough the MS kernel internals is not half bad since it was conceived in the 80s. For believable os level security you need capability based os, better isolation thru micro kernel like techniques, tagged instruction sets (see crash-safe.org), mandatory use of signed code and so on and on.
Stacks come on top of this.
It is a pity that in the era of abundant cpu cores, especially desktops we do not dedicate one core to run protected sub-systems. That core can have a lot more security and can have lower performance. This kind of vertical partitioning favours Ic based kernel interfaces and AMD's HSA will enable such designs assuming hsa has the proper security support.
Std Intel seecurity does not go to the level Trustzone specifies security. FS also adds its extensions to secure boot which helps. There is a reason why AMD licenses TZ and plans to put a Cortex A5 as a sec subsystem in its x86 SoC.
Part of the reason is that the os security mode needed to run full Trustzone is kind of orthogonal to the ring levels of security in the std scheme of things.
The issue is that security has to be thought up ground up. Adding extensions like aes-ni, no execute bit et all over a period of time does not necessarily create a cohesive security model. For example above a certain level of security level, it is preferable to have a sec functional module rather than aes extensions. that function unit can have its own isolated ram, key storage and other isolation features. Which is what FS does and which by the way is not mandated by Trustzone. If I use the main Alu's functional unit for security processing, may leak keys through cache or create other channels for information leakage.
Considering the only requirements we know from the article was "to offer a remote maintenance capability with high security." it's rather far fetched to claim a "poor technical decision" as you maintain. There are lots of reasons, besides the level of security provided, which would come into play in the decision by Daikin; think ease of use, maintainability, support, etc.
Using your reference design for a tablet with military grade security is not revalent as this is not a tablet, not needing to meet military anything, and only "high security."
And, no, I'm not associated with Intel, Freescale, ARM, or anyone else; I'm a retired engineer with well over thirty years experience designing embedded systems.
1. We have used the i.MX6 in a variety of roles, tablets, POS terminal, Bank security devices and soon as a control processor of a quad rotor copter ! We also do automotive and industrial controls for a wide range of scenarios. In fact I rarely do MIL grade stuff. The tablet was a one-off.
2. In most of the apps support, remote maintainability, availability of developers etc were the key. As part of the work I do for the govt. we pretty much end up analysing every procssor family around and we actually have source access to x86 variants and PPC variants aprt from having our own ARM licenses. So our analysis goes pretty deep.
In all the analysis we did, no Intel variant came close to to any of the ARM variants. You name it - power, peripheral support, flexible boot support, esoteric SW libraries. ARM has really penetrated the embedded world in an extraordinary fashion. The x86 instruction set does extract a penalty !
Generally at the Cortex A9 level TI Sitara and Freescale i.MX came out on tops and FS won out due to better docs on security and availability. TI has same features but supporst them only for high volume customers.
But to be fair that was a Cortex part. In general for Cortex M part, NXP and ST are our go to families but FS M4 is a good alternative of late. Only case where we selected a Toshiba part was for brushless DC motor control for HVAC apps where Toshiba had the right HW support. Many Cortex M families had good BLDC libraries but HW support for vector control won me over.
It is based on all this experience, my confident assertion that somebody has not done a good analysis. I suspect that they selected a board or an ODM and the comments was based on the solution rather than the CPU. We also design using the new embedded Atoms (6xx) but only for cases where x86 compatibility is a must. I have put in a request for the new Quarks, let me see what I get !
3. As part of my earlier job where I was the CEO of a reasonable sized design services company, we used to do about 30-50 designs a year for customers around the world. We were also an Intel Yellow book partner for the x86 processor family and probably the lead design house for Intel's Xscale. We did an Xscale tablet for Ericsson back in 1998 . Monochrome, resistive touch. analog modem !
One point that often came through was the design engineers of our customers were often poor at part selection. The reason was simple. As a design services, we had the luxury of being exposed to most CPUs and their usage across a variety of scenarios. For example my HW manager used to ask me to pick up NXP LPCs for certain scaenarios since their I/O drive and pull ups were really good. Customer design engineers typically work on 1 or 2 product families and are stuck with legacy code and hence do not really have the chance to explore.
I doubt we will know Daikin's rationale but the publicly stated rationale I am afraid does not hold water.
I don't know anything, except that AMD64 introduced a lot more than just a bigger address space. IA32 is really not a good/modern ISA, and it would be quite strange to see Intel falling back 10+ years. one real register, stack-based x87, no vectorization, etc. at the time, 64b extensions were justified as not adding a lot of chip complexity - of course that's relative to OoO/superscalar stuff.
At least according to a few software engineers I asked about this subject, symantec and wind river doesn't offer something unique security-related. It's mostly branding.
I wonder if this is the only benefit for this chip, or are there others planned?
Getting better opportunities on the security and embedded internet stack because of very long stay in the computing environment will be a very good plus point for Intel on getting proven in IoT Processor segment.
I am particularly curious to see what packaging options this device will come in. I am wondering if this product is aimed at the Cortex M market, or the lower end of the Cortex A series? If it is aimed at the M, say M4F with a higher clock speed, it would be interesting to see this type of device in a QFN and QFP. If it is competing with the A series, I expect that this will only be available as a BGA.
I will be very much interested to hear this. Some of the Cortex M devices are reaching this level of performance. If Intel comes down this far, and QFN/QFP packages are available, I could see this being a possible device that a hobbiest could use. I will be very interested to see more about this device.
Happy to hear that this tiny chip could give 486, Pentium kind of performance, that would be great!! Will this be somewhere close to the SoC launched by AMD recently: G-series SoC? Probably having lower performance and features than that?
The part that scares me is "...suggesting it is more of a rushed trial balloon than a nailed-down product and strategy."
I would dare not think about using it if there are no clear strategy and a clear road-map. Any tentative timeline announced for its release?
It seems to me that it would make sense to strip off legacy support in a product like this. Why carry along MS-DOS compatability and segmented memory models when they are competing with ARMs that have a much cleaner architecture? The x86 has been overdue for cleaning out the attic for quite a while. Does anyone know if that is what they are doing here?
The 80376 was replaced by the 80386EX, which still kept the static core capable uf running at low clock speeds all the way down to halt to save power. But it also kept the 26-bit addressing, so wouldn't be appropriate for re-implementing at a smaller process size without a major update. But I do think it is probably a shrunken older core. I chose the P54C because it has already been worked on for the Single-chip Cloud Computer project and Larrabee.