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
Is it time for open processors?
101–110 of 236 posts
Re: Is it time for open processors?
#102I know that laws of physics kind of preclude this idea, but a guy can dream.
Re: Is it time for open processors?
#103Earlier 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…
Re: Is it time for open processors?
#104Earlier 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.
Re: Is it time for open processors?
#105Earlier 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.
Re: Is it time for open processors?
#106The 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…
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?
#107The 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…
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?
#108Earlier 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.
Re: Is it time for open processors?
#109Earlier 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?
Re: Is it time for open processors?
#110Open 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.