Live data from Hacker News

Is it time for open processors?

lwn.net

101–110 of 236 posts

Re: Is it time for open processors?

#101
post #64

Earlier quoted context omitted.

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?

Does this qualify? http://www.xtratum.org/files/xm_rtlw09.pdf

Thanks, kind of. It doesn't seem to have been deployed into production, though.

Re: Is it time for open processors?

#102
I know that there are probably a billion technical hurdles for this, but in my perfect universe, CPUs would all be FPGA based; at that point, couldn't updates be almost as simple as a software update?

I know that laws of physics kind of preclude this idea, but a guy can dream.

Re: Is it time for open processors?

#103
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…

It's not a worthwhile project when 99% of your vulnerabilities are in the software and nearly all of them need you to run untrusted software to be exploited. "Browsing the web" is not likely to become a task that can satisfy high security requirements ever again. Too much cruft gets added to browsers faster than it can be thoroughly audited. If you need absolutely no CPU bugs (including bad design decisions "working…

QubesOS is dealing with the problem you describe. It implements security through isolation. But the vulnerabilities in CPU break everything.

Re: Is it time for open processors?

#104
post #103

Earlier quoted context omitted.

It's not a worthwhile project when 99% of your vulnerabilities are in the software and nearly all of them need you to run untrusted software to be exploited. "Browsing the web" is not likely to become a task that can satisfy high security requirements ever again. Too much cruft gets added to browsers faster than it can be thoroughly audited. If you need absolutely no CPU bugs (including bad design decisions "working…

QubesOS is dealing with the problem you describe. It implements security through isolation. But the vulnerabilities in CPU break everything.

The approach is helpful, perhaps not very practical (do I maintain N different browser installations in my qube for N different tasks, or is it a single installation where malware can therefore affect all qubes?). But remember that OS and libraries have plenty of bugs too.

Re: Is it time for open processors?

#105
post #16
post #14

Earlier quoted context omitted.

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.

I'm just amazed how we have two clipboards when I use Linux. Like we can't decide something so stupidly simple.

The two different clipboards are fantastic! Select then middle click is one of the things I miss most on Windows, and it's really convenient that that preserves the copy-paste clipboard.

Re: Is it time for open processors?

#106
post #72
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…

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 think that it was probably introduced ahead of its time, and targeted at the wrong markets, but it's kind of sad that with the Spectre vulnerabilities, we don't have any way of comprehensively addressing it in software without jumping through a lot of hoops and applying microcode updates.

Re: Is it time for open processors?

#107
post #72
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…

I deeply believe that a good set of simple processors (cpu, gpu, apu) could lead to a vastly simpler software layer.

Lots of issues are down to market competition, lies and spec distortion; also double driver games (see the pre vulkan era).

Re: Is it time for open processors?

#108
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…

> 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 I used a couple of Single Board Computers as my main computers for a while a couple of years back and it was really quite painful. Especially web browsing.

Yeah I actually considered that while writing my original comment, it's true that even on a low-end smartphone nowadays browsing certain websites is extremely frustrating. That being said is it really reasonable that the modern web requires multi GHz CPUs, GB of RAM and allowing a turing-complete scripting language everywhere to be able to browse most websites? Is it reasonable that the web is so complex now that effectively nobody but a few giant companies can invest the time and resource to write and maintain the millions of lines of code of a modern browser?

Re: Is it time for open processors?

#109
post #87

Earlier quoted context omitted.

Russia has the Baikal CPU based on MIPS. China has Loongson also MIPS.

Can either be purchased online by customers outside of those countries?

You used to be able to buy Lemote Yeeloong notebooks, which in addition to having Loongsong processors had completely free software BIOS, making them one of the only RMS approved pieces of hardware. But I'm not seeing those readily available any longer.

Re: Is it time for open processors?

#110

Open Processors is a very bad idea. Look at what's happening to Android. The same thing will happen with CPU's. Every OEM will fork the open design and put all of their stupidity inside it in the name of features and security. Bugs like Spectre and Meltdown will become commonplace. The entire time of kernel devs will be spent working around the various 'features' of the OEM designs. Then someone will come up with a J…

Nonsense. OEM can buy ARM "IP" and jam it into a SoC with plenty of poorly designed tweaks and additional devices and it's not happening. Also, open does not mean that random changes are allowed as part of the original design. You can have a license that prevents using the original name of a CPU on modified versions.

As I understand it, the ARM IP license that allows companies to customise the actual cores is very expensive, still requires the resulting customisations to comply with the ARM specification, and relatively few companies have the resources to do so.
Post reply on HN