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

151–160 of 236 posts

Re: Is it time for open processors?

#151

Post by hajile »

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…

IA-64 was a dumpster fire. The halting problem is unsolvable. You can't schedule branch prediction absolutely. You have to have information about the current running program. Branch prediction, instruction re-ordering, and speculative execution are to hardware what a JIT is to software (roughly speaking).

Unfortunately, from a security perspective, moving those things to software doesn't make the vulnerability go away. You can have the same vulnerabilities in your software implementation.

From a performance perspective, we have no general solution to parallelizing a serial program. GPUs used to be VLIW. AMD switched from VLIW-5 to VLIW-4 because the average width was only ~3.5 (Nvidia had switched from VLIW to SIMD long before this). Today, Nvidia and AMD both use a MIMD threaded approach to execute on SIMD units.

Later-generation Itanium chips wound up including branch predictors and speculative execution. From what I understand, under the hood, they were normal RISC-style processors (like all the x86 micro-arch are today). Just ignore the VLIW and run one set at a time serially with the ILP hardware optimizing as it goes.

In today's programs, the programmer specifies data-level parallelism where possible (and if necessary, re-adjusts the code so the compiler heuristics recognize it as optimizable). The compiler then tries its best to detect the parallel data and use SIMD and organize instructions so that the parallelizable ones are closer together (so they fit in the CPU reorder buffer). When they hit the CPU, it examines the code as it runs to optimize speculative execution and uses the reorder buffer to make efficient use of its computation units (load, store, ALU, FPU, SIMD, etc). You move from explicit to implicit-ish (you know that putting similar instructions will optimize in all modern processors), but don't have the drawbacks of noop code bloat or having to compile different code when someone changes from VLIW-2 to VLIW-3 code.

Re: Is it time for open processors?

#152

Post by vanderZwan »

awelkie wrote: post #140
skummetmaelk wrote: post #120

Earlier quoted context omitted.

Then you can increase the power consumption of all electronics by 50+% and halve the processing power. And that is optimistic.

I appreciate what you're saying, but for devices with long lifetimes things may not be so clear. Consider a wifi device with a >15 year lifetime. Let's say such a device was built with SDR and FPGA, it conformed to 802.11b, and it used twice the power of an equivalent ASIC design. But 15 years later, this device was able to upgrade in software to 802.11ac, and so it was able to take advantage of spatial multiplexing…

Even if all of this works, there is still another issue: a potential rebound effect. If mobile phone software has taught us anything, it is that when updates become cheap, we start getting goodness-knows-how-many patches every other month or even week.

How much bandwidth is wasted on redownloading app "updates" every week that represent a few lines of code change?

... huh, I wonder is that is what happened with DNA and those jumping genes.

Re: Is it time for open processors?

#153

Post by Symmetry »

deepnotderp wrote: post #137
lambda wrote: post #106

Earlier quoted context omitted.

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…

Most Itanium implementations had hardware branch predictors+predicates.

To get into trouble you have to be able to resolve one load and launch a new dependent one before the second load is quashed by the branch resolution. There exist in order pipelines that allow that, the Cortex-A8 for example, but they're pretty rare.

Re: Is it time for open processors?

#154

Post by ece »

Somebody needs to take the risks of designing, making, and selling a RISC-V processor/chipset and associated peripherals. Frankly, someone like a Broadcom, who has the expertise, and wants a royalty free rpi, might just work fine. I can't immediately imagine anyone else big enough doing it without upsetting the market too much. Sure, an open foundation could do it if they raised enough cash, but it seems unlikely.

Having the backing of industry/academia/hobbyists is no small feat, and I hope RISC-V can keep pushing further into the consumer market.

Re: Is it time for open processors?

#155

Post by StreamBright »

mickronome wrote: post #30
StreamBright wrote: post #11

I don't see how an open processor would any better than a closed one.

It could add a much needed impetus for the semiconductor industry to consider security perspectives in a much wider sense. Today we can't know or analyse the security properties of the silicon that essentially runs the entire world. We simply have to trust the producers, and they have been proven to be unreliable at best. They compete on performance and features, and the result is not that different from when there w…

If this is true how come that the spectre/meltdown discovery came from external vendors? Black box testing is essential in security and majority of the bugs found with fuzzers and other black box methods. Just because you have visibility into a product it does not mean that you are going to spot the bugs even less, you won't be able to identify security related bugs. Just to give you a really simple example, flying is one of the safest activities for humans yet all of the airplane producers have "closed" development models. It just proves that safety has nothing to do with open or closed development methods. Another angle, do you have documentation of any bridge you use? I don't think so. Yet, it is extremely safe to use bridges. I think people are trying echo the mantra that opensource is safer and testing is the only way to produce reliable products when we know for fact that other engineering disciplines do not use testing and open development, yet produce much safer to use products.

Re: Is it time for open processors?

#156

Post by StreamBright »

pjmlp wrote: post #64
duncan_bayne wrote: post #55

Earlier quoted context omitted.

No - open source is a specific case of the general rule that there is no such thing as a silver bullet :) But it does make possible a bunch of superior workflows that are impossible with proprietary software, and makes certain types of failure common to propriety software much harder.

I am yet to see any open source project subjected to the same high quality workflows as commercial propriety software targeted for high integrity computing deployment. Could you provide an example?

I am not sure when this mantra will stop that open source is safer when we know that it isn't.

Re: Is it time for open processors?

#157

Post by lambda »

pjc50 wrote: post #143
lambda wrote: post #106

Earlier quoted context omitted.

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.

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.

Re: Is it time for open processors?

#158

Post by StreamBright »

dragontamer wrote: post #23
StreamBright wrote: post #11

I don't see how an open processor would any better than a closed one.

Do we really know that AMD is immune to Meltdown aside from trusting them? I mean, I reasonably trust AMD here. I don't see any reason why they'd lie about it. Plus, everyone in AMD seems super-confident that they're immune to the Meltdown issue due to how they implement speculative cache loads. But such analysis is purely within AMD's circle of engineers. None of us outside of AMD can verify their claims.

Do you really trust Airbus and Boeing with your life when you don't have all the blueprints of their planes?

Re: Is it time for open processors?

#159

Post by RandomOpinion »

awelkie wrote: post #140
skummetmaelk wrote: post #120

Earlier quoted context omitted.

Then you can increase the power consumption of all electronics by 50+% and halve the processing power. And that is optimistic.

I appreciate what you're saying, but for devices with long lifetimes things may not be so clear. Consider a wifi device with a >15 year lifetime. Let's say such a device was built with SDR and FPGA, it conformed to 802.11b, and it used twice the power of an equivalent ASIC design. But 15 years later, this device was able to upgrade in software to 802.11ac, and so it was able to take advantage of spatial multiplexing…

> I guess what I'm saying is that by allowing a device to upgrade in software to more power-efficient designs, you might claw back some of the efficiency lost by using an FPGA when you consider the entire product's lifetime.

That presumes you put in a big enough FPGA/CPU or whatever fifteen(!) years in advance that has enough resources to handle the increased processing requirements for a future protocol (expensive and wasteful and there's no guarantee that you didn't guess wrong and it's still too small/slow) and that your RF signal path was designed well enough to handle the new signal requirements (expensive and wasteful even if you were prescient enough to guess what future requirements were). And that's on top of the fact that inexpensive electronic devices simply aren't built with components rated to last 15 years.

tl;dr software doesn't change the laws of physics

Re: Is it time for open processors?

#160

Post by dirkt »

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…

Have a look at Risc V [1], in the meantime backed by quite a few biggish companies [2]

[1] https://riscv.org/

[2] http://www.tomshardware.com/news/big-tech-players-risc-v-arc...

Post reply on HN