back to article Intel's answer to ARM: Customisable x86 chips with HIDDEN POWERS

With new CEO Brian Krzanich and new president Renée James in control of Intel, all kinds of changes are very likely in store: the chip giant wants to expand beyond its dominance in PCs (a declining market) and servers (one that is profitable but not growing very much) to other aspects of the computing landscape. And one such …

COMMENTS

This topic is closed for new posts.
Thumb Down

Security

End customers should know all that they're getting. Having hidden features that some third party can secretly exploit is a security threat to both the customer and to the manufacturer.

If there were a zero-day exploit that made use of such a feature, the results could be devastating for both customers and Intel. People still remember the damage done by the floating point bug. They'd never forget a security vulnerability that was secretly hidden in a processor.

14
1

This post has been deleted by a moderator

Bronze badge
Stop

Re: Security

If there were a zero-day exploit that made use of such a feature, the results could be devastating for both customers and Intel.

That seems to be a mighty big "if".

While a system relying on those silicon extensions could have issues if the extension were flawed it is difficult to see how faulty silicon could be used to create an exploit elsewhere. The flawed extension would have to affect something else the system relied upon for security to achieve an exploit through its use.

You could argue that every part of any implementation within silicon is an exploit just waiting to happen - and that may be so - but it seems a case of confusing threat with risk when it comes to how likely that would be.

2
7
Anonymous Coward

Re: Security

Do you think you could ever post anything without bringing up MSFT/Windows?

5
7

Re: Security

Normally, additional features that command a premium are fused-out in 'common' silicon and enabled only for special SKUs.

To temporarily enable fused-out feature you would need several things none of which are present in the computers employed in ordinary businesses. And even if you had all the tooling and clearances (which is next to impossible) the process of temporary enabling is not going to be unnoticed. Hardly something that can be used for exploitation. There are much easier avenues - including more and more rare kernel-level exploits.

2
0
Anonymous Coward

Re: Security

"Do you think you could ever post anything without bringing up MSFT/Windows?"

Give the guy a chance, sometimes he has a real point which is lost because of the name attached (which is one reason why I carry on posting as AC, then readers have to draw their own conclusions).

The x86 is largely only relevant when a system needs to have the capability to run Windows (exceptions apply, but not many)..

In volume markets where x86 is not relevant, there is no Windows (look around you).

In volume markets where Windows is not relevant, there is no x86 (look around you).

In volume markets where Intel want to be relevant, they just found a way to lock out AMD, if I'm reading this right.

May not be such a good move for Intel, or their customers (whether or not they depend on the special features)..

Good move for the anti-trust lawyers though. Anti-trust lawyers don't like things like undocumented APIs. Afaict, this is conceptually equivalent.

Trebles all round for the lawyers (as usual).

7
0

This post has been deleted by its author

Bronze badge
Megaphone

Re: Security

Having hidden features that some third party can secretly exploit is a security threat to both the customer and to the manufacturer.

Nope. This isn't like software. More often than not the feature is locked out, often at the mask level. And there are other sneaky ways to prevent unauthorized use. This has been going on for years. The difference is, while software engineers can't stop talking, hardware engineers don't talk.

BTW, when you add features to a core like this it's called a Microcontroller.

Or, another sneaky thing we like to do with microcontrollers/SoC is I offer a high-end, high priced chip with the cool feature, while also having the same feature on a cheaper chip BUT undocumented. So I have people buying the cheaper device from me using the expensive feature (ripping me off). After two years I mod the cheap device so the advanced feature isn't available anymore. Customers call to complain, I tell them "Hey, that feature isn't on that device". Now they are forced, forced to pay more money for the more expensive device! REVENGE!

2
4
Silver badge

Missing the long term problem

Sure, they are now near copying ARMs approach and try to appeal to handset makers in that way, but that's not the long term problem. We are now in the "home computer" age of mobile computers. Every manufacturer has a totally different platform. If you are lucky you get some dedicated port of some operating system (i.e. Android) which won't be supported and which you will be stuck with.

In the home computing age the IBM-compatible PC arrived, sweeping away its competitors. Suddenly you had a machine that could run different operating systems, where you could upgrade the operating system just by booting from a different diskette.

If Intel wants to succeed in the long run, they must bring real advantages over ARM. For example they could create a SoC with a little boot ROM which allows booting from an SD-card. That ROM could also have routines to access the hardware, kinda like a BIOS. (But please not as complex as UEFI)

One of Intel's strengths in the 1970s and early 1980s was that they provided full developer support. For example you could buy their development system and it would include a full Pascal compiler, while the other vendors still required you to hand-assemble your code. Intel should try to do the equivalent of that today. Make it easy to build a mobile device and slap your software onto it, just like it's easy to slap a new operating system onto a PC.

They wouldn't be successful with it at first, but once all those tiny Chinese manufacturers get a hold of this they will have conquered the mobile devices market.

4
1

This post has been deleted by a moderator

Re: We need fewer registers not more!

RISC chips have _more_ registers

11
0
Anonymous Coward

Re: We need fewer registers not more!

"I'm not an expert in what they are up to, but Intel seem to be going in the wrong direction. They should be going RISC."

If you know you're not an expert then keep out of things until you've done some research and think you are. Otherwise you're just the forum equivalent of interference on the radio. Again.

14
0
Silver badge
Unhappy

Re: " Otherwise you're just the forum equivalent of interference on the radio."

Entirely standard practice for that gentleman.

6
0
WTF?

Re: We need fewer registers not more!

Dear lord. The main problem with x86 chips is that they are register starved. How many general purpose registers (GPRs) does x86 have? 6. But the x86_64 chips manage to get as high as 14 GPRs. Whew!

Even 32 bit ARM chips manage to have 16 GPRs for goodness sake. SPARC has 31 and Itanium 128 GPRs.

As any electrical engineer or anyone who has had the misfortune to have to do any Assembly programming will tell you; only having 6 usable registers is a massive pain in the behind.

1
0
Silver badge

Re: We need fewer registers not more!

The days of significant difference between RISC and CISC processors is long past.

What you might call RISC are gaining more and more instructions (see the ISA for both Power and later ARM versions), and what you might think of as CISC are often built using microprogrammed RISCy cores (intel since 486's and even IBM zSeries).

Almost all architectures have many, many registers, and often use techniques like register renaming to allow fast context switches.

6
0
Anonymous Coward

Re: We need fewer registers not more!

"SPARC has 31 and Itanium 128 GPRs."

Careful. Your point is actually valid, AMD64 supports it, as does recent ARM, but you'd have done better not ti quote SPARC or IA64 as relevent modern examples of much in particular.

Itanic had so many registers that a context switch had to be scheduled three weeks in advance otherwise you took (yes past tense) a massive performance hit.

1
0

Re: We need fewer registers not more!

Actually, SPARC had 128-160 registers (depending on version) - but only 32 were visible at any one time (and one constantly held the value 0 for comparison and initialisation purposes.) The 24 In / Local / Out registers were commonly used for local storage, plus passing values to/from subroutines; every time you called a subroutine, the In / Local / Out registers shifted, so 8 new registers were visible to the called subroutine, and 8 shifted out of view. In this way, it was very efficient to pass values to/from functions without the need to copy pointers.

In addition to the In/Local/Out registers that shifted, there were 8 global registers that did not change when you called a subroutine.

3
0
Bronze badge

Re: We need fewer registers not more!

Modern CISC cores are more efficient than RISC cores. Also, CISC is more suited to embedded processing.

0
4

This post has been deleted by a moderator

Silver badge
Thumb Up

Definitely an old practice. The Z80 had a whole slew of undocumented instructions relating mainly to the index registers. Probably just an artefact of the way the prefix instruction worked though rather than a deliberate attempt to release them at a later date.

3
0
Silver badge

Z80 ?

IIRC, wasn't one of the dangers of using undocumented opcodes that they could vary across fabrications ? Just because a Zilog processor worked didn't mean an OEM one would ?

0
0
Silver badge

Re: Z80 ?

Yeah, they used to warn that. I've no idea if it's true but there were so many variations on the chip that it's entirely possible.

1
0
Anonymous Coward

Re: Z80 ?

" there were so many variations on the chip that it's entirely possible."

And how many second sources do you think Intel is proposing to permit for this technology?

2
0
Bronze badge

Re: Z80 ?

Yup, and as AndrueC said, "they" (in my experience assembly language instructors) would warn against using them. There was a certain "I know the secret code!" thrill about knowing them, but I'm not a teenager anymore, and getting code -- especially assembly code -- to work everywhere soon hammered any idea of using them out of my coding practice.

1
0
Silver badge

The Z80 (and 6502, and others) undocumented opcodes were merely relics of the decoding process — they weren't intended to be hidden. The reason they became well known was that one or two of them were found to do useful things in computers where a single supplier had provided the same model of CPU for the entire production run.

For example, there's 'shift left and insert a 1 in the least significant bit' on the Z80 that can be used to make a faster scroll in some cases and to help with certain methods of sprite compositing. It's a relic of shift right arithmetic and fills a pretty obvious numerical hole in the instruction map. So if you know that every 48k Spectrum uses a Z80 with that instruction then why not use it?

So this is unlike the classic situation because the motivation is different — the new operations are hidden on purpose.

1
0
Anonymous Coward

The whole point of Intel's manufacturing prowess is that there ARE no chips with "Unusual frequency and temperature characteristics". They are ALL THE SAME! . So there is no (or very little) bin sorting.

If you're not in control of your process, there is a chance that you'll wake up one morning with a FAB that makes chips you can't sell.

The days of Bin1 = 12MHz are over.

I'm ex-Intel from the 1980s and 90s and in my parts box is a 40pin DIP labelled "8086 - FAST".

1
0
Anonymous Coward

Intel doesn't really get it. It's not about them producing x86 custom chips for different customers, it's about licensing the IP and letting customers put the production out to tender and taking advantage of the marketplace.

Intel just doesn't want to lose the monopoly they have in producing x86 CPUs using genuine Intel designs.

4
0
Gold badge
Boffin

"Intel just doesn't want to lose the monopoly they have in producing x86 CPUs using genuine Intel designs."

At the genuine Intel price.

5
0

Intel is getting desperate

With AMD's customized APUs winning all three gaming consoles plus a lot of other market segments including some that use ARM chippies, Intel has fallen behind by several years. It's good to see AMD deliver better tech at lower prices.

5
1

Is it really a good business model ?

It looks like a lot of work for each customer. As the versions proliferate then things can get extremely complicated.

0
0
Anonymous Coward

Did Waxman really say "and et cetera"?

1
0
Gold badge

Golden screwdriver.

I thought that referred to the practice of the extra bits being available on all chips, but only turned on when you paid for the privilege?

This would appear to be more of a custom ASIC approach, where you pay up front for a custom chip, only where said ASIC happens to be a shonky old x86 CPU with some extra sequins sewn onto its frock.

0
0
This topic is closed for new posts.

Forums