Is it time for open processors? • Hacker News Board

Re: Is it time for open processors?

#191

Post by Aloha » Fri, Jan 19, 2018, 9:20 PM UTC

ken wrote: post #167

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 think there's a huge difference between "take an existing system design, and declare it open" and "design a system in the open". This article isn't suggesting Intel make x86 open to all, for example. You get a completely different design when something is designed behind closed doors as a black-box product, versus designed in the open. Linux and Windows have drastically different designs, based on how they grew up.…

> I think there's a huge difference between "take an existing system design, and declare it open" and "design a system in the open". This article isn't suggesting Intel make x86 open to all, for example. You get a completely different design when something is designed behind closed doors as a black-box product, versus designed in the open.

I don't - I believe there are an insufficient number subject matter experts conversant enough in processor design to provide the depth of auditing needed.

I'm not saying openness is good or bad (its usually good) just that its not a panacea here.

Re: Is it time for open processors?

#192

Post by int0x80 » Fri, Jan 19, 2018, 10:21 PM UTC

em3rgent0rdr wrote: post #189

int0x80 wrote: post #148

Earlier quoted context omitted.

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'…

Was is a unintentional bug , or was a deliberate design tradeoff favoring performance over security?

I'm assuming the former, but I could be wrong.

Re: Is it time for open processors?

#193

Post by lambda » Fri, Jan 19, 2018, 10:27 PM UTC

jasonwatkinspdx wrote: post #178

lambda wrote: post #157

Earlier quoted context omitted.

Oh, yeah, I'm aware of many of the reasons that IA64 failed. Intel could have solved this problem by contributing to GCC and LLVM instead of keeping their optimizations proprietary. Then they would also be more easily auditable as well.

> instead of keeping their optimizations proprietary There were no magic secret optimizations to release. It just straight up did not work. They had to add back dynamic branch prediction, and even then the load store latency was such trash that they had to put ginormous L3 caches on it to get even close to reasonable performance.

That's fair. I have never worked with them, so I don't know the precise details; but one of the big complaints I've heard was that compilers weren't ready for them yet, while these days there's now a larger field of open source compilers and has been a lot more research in parallelism.

Re: Is it time for open processors?

#194

Post by riffraff » Fri, Jan 19, 2018, 11:14 PM UTC

simias wrote: post #72

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'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…

ARM is a UK company isn't it? Also, minor electronic manufacturers like STM are still around in europe, I think. No big foundries but it seems there is enough competition to survive a shut off of a single partner, unlike the GPS case.

Re: Is it time for open processors?

#195

Post by B-Con » Fri, Jan 19, 2018, 11:52 PM UTC

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.

Right. But how long did that take? The problem had been around for years.

Re: Is it time for open processors?

#196

Post by em3rgent0rdr » Sat, Jan 20, 2018, 12:11 AM UTC

int0x80 wrote: post #192

em3rgent0rdr wrote: post #189

Earlier quoted context omitted.

Was is a unintentional bug , or was a deliberate design tradeoff favoring performance over security?

I'm assuming the former, but I could be wrong.

The risk of speculative updates to branch predictor and page tables was known to the research community for a while. Even if it was initially an unintentional bug, they had plenty of time to take precautions against it by prohibiting speculative updates.

Re: Is it time for open processors?

#197

Post by andyidsinga » Sat, Jan 20, 2018, 1:13 AM UTC

re "solution to the hardware problem" in post:

a glance at opencores.org shows some interesting prospects under the processors and system on chip categories.

ex. - https://opencores.org/project,rv01_riscv_core - https://opencores.org/project,riscv_vhdl

Re: Is it time for open processors?

#198

Post by bastawhiz » Sat, Jan 20, 2018, 2:28 AM UTC

mandelbulb wrote: post #114

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…

>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. How about, discovering it? That's one of the points of openness, not somehow being inherently better in a way. At least we have a spec manual in this case. Also, audits should be peer-reviewed, that's difficult without openness.

Heartbleed was in OpenSSL for years before it was discovered. It was readily auditable with plenty of docs and specs and yet nobody noticed.

Re: Is it time for open processors?

#199

Post by bastawhiz » Sat, Jan 20, 2018, 2:35 AM UTC

DarqWebster wrote: post #17

therealmarv wrote: post #10

Open does not mean better. This is not how our world works. Would be nice to have but I assume every Intel chip I can buy (even with the throtteling) will be more powerful and cheaper than any open processors. There is also much more than only architecture this thing (this works in software but not in hardware)... this would only work if a big player like AMD or Intel jumps on this ship (but it would be like giving a…

If one only considers power / speed and cost, then open will certainly mean worse. However a processor with verifiable functionality has value. It's more trustworthy. It can be checked for accidental, or deliberate, security flaws. In many scenarios, I don't care how fast a processor is, if it's leaking data then it's worthless.

> However a processor with verifiable functionality has value. It's more trustworthy. It can be checked for accidental, or deliberate, security flaws.

Is this tractable for a chip with billions of transistors? I would think the people qualified for this already work at chip companies and are doing the work for a stable salary.

Re: Is it time for open processors?

#200

Post by gravypod » Sat, Jan 20, 2018, 3:11 AM UTC

I'm interested in the possibility of eventually having FPGA-driven systems where you can load up an ISA and use that. Imagine if every week you could expect an ISA architecture update that came with a power usage or speed improvement.