Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is it time for open processors?

lwn.net

Post reply on HN
Print view View original

141–150 of 236 posts

Re: Is it time for open processors?

#141

Post by earenndil »

weego wrote: post #14
earenndil wrote: post #6

Earlier quoted context omitted.

Perhaps the solution is some form of interoperability across processors. Where they primarily run one ISA but have a dynamic converter that can based on some flag interpret memory as code from a different ISA? As chip fabbers and ISAs compete eventually a clear winner emerges and these compatibility layers are mere curiosities just like 16-bit mode on modern x86 CPUs. Except wait, maybe this is just my cynicism talki…

Interop relies on a single standard as a benchmark and history tells us that people are incapable of being content with a standard that isn't exactly how they imagined it and would rather fragment and live and die on their own hill than play nice.

> Interop relies on a single standard as a benchmark

Not so! Imagine that each processor is made by their own company (to simplify it) and has its own ISA. Thus, processor A can emulate processors B and C, B can emulate A and C, and C can emulate A and B.

Re: Is it time for open processors?

#142

Post by ableal »

mpweiher wrote: post #63
icelancer wrote: post #45

Earlier quoted context omitted.

>often superior This is a little hyperbolic. There have been occasional superior alternatives but "often" is kinda silly. By and large, the best products won - and that is despite accepting that Intel acted in anti-competitive ways in the past (Cyrix et al).

> best products Agreed, somewhat, but you are conflating "product" and "architecture". I specifically meant architecture . Intel was usually at least one process generation ahead of competitors, and often more than that. With Moore's law still going at full tilt, that meant not only more transistors, but also faster transistors, completely overwhelming the architectural deficits. > occasional superior alternatives bu…

Plus the NS 32000, "likely the first 32-bit general-purpose microprocessors on the market", https://en.wikipedia.org/wiki/NS320xx

Re: Is it time for open processors?

#143

Post by pjc50 »

lambda wrote: post #106
simias wrote: post #72

Earlier quoted context omitted.

I'd pay good money for an open and simpler platform to run my security-critical tasks that don't require top performance. Auditing a modern high-end CPU is probably a huge task even if you have access to the HDL because of how complex they are. A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web, send emails a…

Why give up on performance? IA-64 ( https://en.wikipedia.org/wiki/IA-64#Architecture ) already exists, with its explicitly parallel instruction set, which leaves branch prediction and speculative execution up to the software. So you can still get many of the performance benefits, but it's under control of the software, giving a lot more flexibility for being able to mitigate or eliminate these kinds of issues. I thin…

I think this is overlooking how unpopular IA64 was.

"Leaves branch prediction and speculative execution up to the software" means that in practice you need to either use the Intel compilers or hand-optimise your software to get the benefits, while simply recompiling your legacy software with GCC or LLVM ends up being disappointingly slow.

Re: Is it time for open processors?

#144

Post by baybal2 »

B-Con wrote: post #34

The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore o…

>As I understand, these latest CPU vulnerabilities were in the spec themselves.

And yes, 20 years ago Intel was called out for that. In a narrow circle of electronic engineers specialising in CPU designs, this quirk was a know source of worries.

Re: Is it time for open processors?

#145

Post by mpweiher »

tjoff wrote: post #85
cm2187 wrote: post #69

Earlier quoted context omitted.

Because the compute power for consumer CPU nowadays is good enough, the effort has been in reducing energy consumption. But if you look at the server / workstation side, you can get 20+ cores in a single dice.

Good enough relative to the competition perhaps. Nowadays the CPU is the bottle-neck even when surfing the web and using simple (electron) text editors.

But that's not really a CPU problem but a software problem. And faster CPUs won't fix it, due to Wirth's Law.

Re: Is it time for open processors?

#146

Post by baybal2 »

nerdponx wrote: post #113
B-Con wrote: post #34

The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore o…

As I understand it, according to an article that was posted here a day or two ago, Meltdown was in fact discovered by a young Google engineer poring over the x86 manual.

No, only those 3 particular exploit methods. P3 branch predictor peculiarities were known before, but were refuted as unexploitable.

Re: Is it time for open processors?

#147

Post by ryanlol »

lambda wrote: post #106
simias wrote: post #72

Earlier quoted context omitted.

I'd pay good money for an open and simpler platform to run my security-critical tasks that don't require top performance. Auditing a modern high-end CPU is probably a huge task even if you have access to the HDL because of how complex they are. A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web, send emails a…

Why give up on performance? IA-64 ( https://en.wikipedia.org/wiki/IA-64#Architecture ) already exists, with its explicitly parallel instruction set, which leaves branch prediction and speculative execution up to the software. So you can still get many of the performance benefits, but it's under control of the software, giving a lot more flexibility for being able to mitigate or eliminate these kinds of issues. I thin…

>targeted at the wrong markets

What would have been the right ones?

Re: Is it time for open processors?

#148

Post by int0x80 »

B-Con wrote: post #34

The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore o…

I really don't think that the speculative execution _implementation_ was in any spec whatsoever.

The fact that it did the protection domain check later in the process was not documented by Intel at all for example.

Having said that, the implementation was (obviously) available for Intel engineers and they didn't spot the problem in 10+ years.

Bugs will happen, especially this kind of bugs that people generally haven't had in mind in the past.

Re: Is it time for open processors?

#149

Post by int0x80 »

saas_co_de wrote: post #122
B-Con wrote: post #34

The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore o…

> You could've found them by reading the manual Pretty much. Everything you needed to figure this out was public. Just publishing stuff doesn't help much in areas this complex and specialized where there are a very small number of people who can really understand what is published. There is also a major difference between reading a spec and discovering an exploit through an adversarial process. Nobody who had complet…

I'm sorry but the implementation of the speculative execution or the branch predictors was not available at all.

Could you tell for example that AMD wasn't vulnerable to meltdown but Intel was by looking at any docs? Not really.

Re: Is it time for open processors?

#150

Post by jhasse »

saas_co_de wrote: post #122
B-Con wrote: post #34

The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore o…

> You could've found them by reading the manual Pretty much. Everything you needed to figure this out was public. Just publishing stuff doesn't help much in areas this complex and specialized where there are a very small number of people who can really understand what is published. There is also a major difference between reading a spec and discovering an exploit through an adversarial process. Nobody who had complet…

> There is no reason to think that the people who figured it out would have been aided by having more internal documentation.

Why not?

Post reply on HN