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 or sweep under the rug if it's inconvenient to business.
The problem of course is that it's probably a very niche market at the moment. Most people probably don't really understand what's at stake and might not even care either way. As such I don't expect that people could manufacture open CPUs and sell them at a reasonable price. So you'd end up with overpriced, under-powered CPUs which won't drive adoption.
I can't imagine such a project being successful if it's not backed by a big company or a government. I kind of wish the European Union would try its hand at it, after all computing is absolutely critical these days (and it's only going to get more critical as time passes) yet we're completely dependent on american and chinese companies to provide us with CPUs. If the EU thought that Galileo was worthwhile to have our own positioning system certainly it also makes sense to have our own CPUs for critical tasks?
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.
Would you consider installing and running dozens of random untrusted 3rd party applications every day on your real OS even if they were (somewhat poorly) sandboxed? Because that's what the modern web is like.
I wouldn't mind opting-in to additional "interactive" features for webapps that I want to trust but having everybody (including 3rd parties of 3rd parties of the website I'm browsing) run code on my computer when I'm on some random webpage is just insane when you take a minute to think about it.
Gmail or Facebook aren't the problem. People could be convinced to use desktop apps for them fairly easily (just like they do on their phones). The issue is all the other one-off apps. Users can't be bothered to go and download some random app, so the company runs that app in the browser. You simply cannot fight that level of market pressure.
China has Loongson also MIPS.
And since it's ARM, it's at least half-open.
Cloud providers will be interested - slower cpu's = more money, plus selling the cloud as a more secure option to your data center.
And once you have a cpu that with a hardware switch can become more secure but slower, maybe there's a decent enough niche somewhere.
What do you mean by that?
That's the real problem with an open platform, whether it's about hardware or about software. To get enough funding, support, and manpower an open secure platform initiative would have to get entangled with global players that simply do not have the ultimate privacy and security of all citizens in mind. It's primarily a political issue.
"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 as intended"), take a well-understood, possibly older design like 680x0 or MIPS and run it on an FPGA.
Single-thread performance would suffer, though, unless you're ready to pay quite a lot. And it's still hugely important in many cases.
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.
"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.
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.
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.
Yeah, compilers today are no better. We found the limits of statically scheduled parallelism pretty fast. On code that uses static scheduling, a modern OoO processor can easily duplicate what IA64 was capable of (and a pipelined loop using AVX will utterly smoke it), while being far better at all the stuff IA64 failed at.
I remember going to a corporate presentation by Intel about the revolutionary CPU architecture. They had to turn the machine off because the cooling fan was making so much noise we couldn't hear the speaker.
And this at precisely the wrong moment in history, as mobile devices, with their stringent power consumption constraints, were becoming popular.
What would have been the right ones?
PS3 with Cell would have been a failure had Sony not eventually caved in, and released a PS3 SDK that made most of the work Sony was initially expecting devs to do, regarding low level programming.
That work became PhyreEngine.
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.
Can you elaborate on how the halting problem relates to the IA-64 architecture?
In the context of IA-64, that means that generally, the compiler will not be able to determine when it's save to use parallelism. We can only program it to use parallelism in a bunch of special cases for which we think it will be safe.
Given that simias originally asked for a simpler platform that we can trust in more, this seems to be a pretty strong argument that IA-64 is not that architecture.
In particular, you end up losing the ability to avoid stalling on cache misses, and the memory wall becomes an increasingly gigantic problem even as Moore's Law progresses.
We don't need to give up on performance, even with low-performance RISC-V chips. What we need is a new architecture which takes advantage of low-speed multicore processors. If it is possible to produce thousand-core RISC-V chips [1] then any core could be assigned a single thread - which implies that there is no need for a complex multitasking OS.
[1] Towards Thousand-Core RISC-V Shared Memory Systems (PDF)
https://riscv.org/wp-content/uploads/2016/11/Wed1000-Thousan...
Lots of issues are down to market competition, lies and spec distortion; also double driver games (see the pre vulkan era).
As you said, 99% people don't care about security. It's hard enough to get people to use ddg over google, making them use open source processor thats likely slower and costlier would be practically impossible.
[2] http://www.tomshardware.com/news/big-tech-players-risc-v-arc...
Linux and Windows have drastically different designs, based on how they grew up. Early Mozilla releases were open-source, but still "bore the scars of many rapid cycles of closed-source development" [https://en.wikipedia.org/wiki/History_of_Mozilla_Application...]. From the recent news, it seems that StarOffice is finally becoming somewhat hackable for us mere mortals (who don't speak German). It's the process, more than the license. An open license enables an open process.
"Magic bullet" implies you've got something evil (x86, with bugs!) and want to magically transform it (x86, with no bugs?), but nobody is proposing that. It sounds more like they want to put Conway's Law to work for us (e.g., RISC-V).
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.
Is that still being hacked on? I thought most of the OO people moved to Libre Office
> more about quality of auditing.
Exactly. Being open makes things easier to audit, and to an extent encourages better due diligence (as embarrassments due to silly mistakes or, worse, attempted cover-ups, are more public!), but it doesn't enforce this in any way nor does it guarantee quality or completeness.
...and if I in fact identify any shortcomings, I can help others not to get hit by them, which makes the concept of openness "safer" in a way that is the sum of collective knowledge.
I'd actually love to see a bazaar on the cpu side of things, be it just for the sake of what community efforts can achieve as opposed to the current mostly proprietary ecosystem.
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.
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 complete access to confidential data (at Intel or anywhere else) figured this out. People on the outside working with an adversarial process did.
The adversarial process is driven by testing not documentation. There is no reason to think that the people who figured it out would have been aided by having more internal documentation.
Could you tell for example that AMD wasn't vulnerable to meltdown but Intel was by looking at any docs? Not really.
Why not?
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.
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.
I recommend reading the Google project zero blog post on them - they're easy to follow.
and just to be clear, the least whatever you are doing in a closed format affects people the least i want it to be open.
But closeness makes it extremely difficult to find actual backdoors left on purpose. Open processors would be a first step in the right direction.