Is it time for open processors?
lwn.net
lwn.net
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.
> 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.
I recommend reading the Google project zero blog post on them - they're easy to follow.
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...
But closeness makes it extremely difficult to find actual backdoors left on purpose. Open processors would be a first step in the right direction.
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.
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?
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.
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.
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
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.
The website I posted links a few pdfs for more info.
There would need to be significant player buying these processors to make them viable for some smaller entities to be able to piggy back and purchase as well.
Not necessarily if it is a "viral" license like gplv3 agpl, no?
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.
Agreed, but for critical applications it might be appropriate.
> If your security demands are that high I'm sure you will find even nowadays CPUs which are in that level of "trustworthyness" you want. One funny example: You can use a Raspberry Pi which is not affected by Meltdown or Spectre ;)
Having the level of verificability the parent asks for is a lot more than "not affected by Spectre", and the Raspberry Pi is not very open in that regard.
But is wanting to know what my processor is doing, or wanting it to be free of undocumented, obfuscated, proprietary code that runs at a higher priority than any software, really that extreme a view?
We base so much of human progress on these little wafers of silicon, it shouldn't be extreme to want to know what they do.
Well said. I'll add that security is a threshold, and that computer systems are extremely complex. Every bit of openness -and the verifiability such openness affords- brings us closer to that ideal secure system.
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.
Risc-V is going to allow extremely cheap processors. They will probably not match Intel's single thread performance ever though.
The meltdown/spectre vulnerability was there not because people didn't pay attention, it's because nobody thought of these optimization features as potential vulnerabilities. And honestly it's hard to blame anyone, these were really smart hacks!
>Finally, even if we end up with entirely open processors, that will not bring an end to vulnerabilities at that level ... Open hardware may give us more confidence in the long term that we can retain control of our systems, but it is certainly not a magic wand that will wave our problems away.
The author is arguing more from a freedom/control perspective from what I understand. When it comes to these kinds of vulnerabilities, an open CPU might be easier to patch or easier to disable the affected components of.
Apart from that, maybe crowd-sourcing and open-sourcing the eventual fix is faster or better than a private org. That doesn't necessarily seem like something the author is saying, but it seems like a reasonable factor to consider. I can see arguments either way that I'm not really qualified to defend.
There are, and have been a few CPU/MCU upstarts that have actually done shorter runs of silicon, and while they are usually quite well funded, the numbers doesn't seem to be prohibitive at all.
If the need was there for it NOW, fabbing something with existing open ip is quite likely to be 'free money' (or free market share), as the semiconductor industry appears to be entrenched with ip licensing so much that I sincerely doubt that they would be quick to follow suit. If only because any open offering from them would be seen as detrimental to market dominance, and lower the value of ip cross licensing deals.
Unfortunately I don't think the market need is there, and won't be for quite some time. I would love to be wrong though.
Shuttle service costs for small runs of silicon are, for most people in most situations, tens of thousands of dollars at a minimum. My argument is that if the price dropped to the point where it was competitive with FPGAs at prototype scale (eg, 10 parts might cost $1000 but not $10000) then you would see parts on the market built that way quite quickly. I think the proof for that is the number of low volume commercial parts (HSMs, LTE base stations, etc) which carry FPGAs today. Seems the market has already spoken?
I know that laws of physics kind of preclude this idea, but a guy can dream.
I mean, it's not like the other types of electronics are inherently energy-efficient either: before it affected battery life people didn't care that much about energy-efficient CPU's. The current drive for more computation per Watt is largely driven by the explosion in mobile hardware.
Perf/Watt has always been interesting as well, It's a major concern for data centers (worse perf/Watt requires more cooling which drives costs up).
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.
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.
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
We have some idea of how to do massively-parallel programming. That is, after all, what a supercomputer is. But one of the things we've found is that communication doesn't scale. For very low core counts, you can hook up each core to talk to every other one at the same latency--basically, O(N)-degree topology. For slightly higher core counts, you can keep it a hypercube, which is O(lg N) degree. But when you start thinking about a few hundred cores, you end up with a mesh, which is O(1)-degree.
What that means is you struggle to scale problems that have very high communication costs compared to computation. Matrix multiplication is wonderful--you're doing O(N^1.5) computations for each data, so communication goes down as size goes up [1]. But a BFS graph traversal is horrible, because your communication costs go up if average degree is more than O(1).
[1] This is why the TOP500 benchmark is to some degree bullshit. It's measuring performance on applications that are fundamentally computation-bound, not communication bound, so it tends to penalize machines that focus on improving communication bandwidth, which is often helpful for many HPC applications.
Even the later "fat processor" (RISC) Connection Machines had several hundreds of CPU (the earlier models had tens of thousands of single-bit processors)
Today most software can only scale if you add a faster processor, that has to stop, before that happens, there is not much the processor manufacturer can do, their hands are tied IMO
> Today most software can only scale if you add a faster processor, that has to stop, before that happens, there is not much the processor manufacturer can do, their hands are tied IMO
These are not recent developments, chip makers could have opted not to use them and software developers would have done otherwise.
The hardware is developed to make the existing software faster, but the software is also developed to run well on the current hardware.
The programming interface of a modern x86 CPU is best thought of as a virtual machine with a JIT. The JIT performs some optimizations to make old code run more in parallel without the need for recompilation. This is a terrible model for compilers and programmers, since it makes optimizations hit or miss, and of course it's why we're in this whole spectre/meltdown mess at the moment. If we switched to a more reasonable programming model which actually met the needs of software (fine grained interprocessor communication without going through central memory, many more registers, actual software access to pipelines, caches, etc.) then it would make a lot of old software run slower (through emulation), but new software could finally make better use of your hardware...
Seeing how Itanium went, their risk aversion seems pretty wise.
Itanium seems to satisfy most of your desires with its VLIW/EPIC architecture, which exposes much more to the compiler.
Except wait, maybe this is just my cynicism talking, but I have a feeling intel has the resources to just plough forward with x86 and prevent any competition from gaining a foothold in the markets where they hold dominance (laptop, desktop, server). ARM continues to dominate mobile and perhaps some small portion of servers. POWER and SPARC stay in their little niches. Perhaps RISC-V makes its way into a couple of embedded appliances. And that's it, for the foreseeable future.
So you still have two, at least with Gnome 3 on Wayland.
I am so glad to hear they are fixing this in wayland and there will be only one clipboard by default going forward.
Not so! Imagine that each processor is made by their own company (to simplify it) and has its own ISA. Thus, processor A can emulate processors B and C, B can emulate A and C, and C can emulate A and B.
Also, relative strengths of the OS (if thread creation is relatively slow, it may not be worthwhile to multi-thread a short code fragment; one OS might have three kinds of spin locks, another only two; if there are many registers, you may need larger stacks per thread, and may want to limit the number of threads in memory-constrained devices) are bigger ones.
IME it’s harder to port to a new os than a new ISA.
Computers were sold with hardware and software designed to work together and provide a full stack experience.
Not a puzzle of bits-and-pieces.
The only programming language I actually do have care about the underlying OS is C, due to its dependency on POSIX as an extension of ANSI libc.
"Fragmentation"??
We have a huge monoculture of Intel x86/x64 on the desktop, driven by Intel's fab advantage that smothered all alternative (and often superior) architectures. And recently, a second one has sprung up with ARM on mobile.
And it hasn't really been good for the industry.
Fortunately, the Windows monoculture in OSes has been broken, so much that MS wasn't able to extend it to mobile and has been driven to give away their OS updates.
In terms of porting, CPU architecture is far less of a problem than you might think. Tiny NeXT managed to make its OS available for four CPU architectures: 68K, i386, SPARC and HP-PA, with apparently PPC and MC88K available in-house. Write Once, Run Anywhere™, all with native binaries, no intermediate layer needed.
And these were processors with different endian-ness, RISC, CISC, sliding register windows, sparse register sets etc.
Intel's problems over the past year aside, they have done an amazing job pushing the limits of computation over the past decades.
Not that core count is everything but consumer desktop CPUs have stagnated quite a bit. Here's to hoping AMD stirs it up a bit.
Nowadays the CPU is the bottle-neck even when surfing the web and using simple (electron) text editors.
This is a little hyperbolic. There have been occasional superior alternatives but "often" is kinda silly. By and large, the best products won - and that is despite accepting that Intel acted in anti-competitive ways in the past (Cyrix et al).
Agreed, somewhat, but you are conflating "product" and "architecture". I specifically meant architecture.
Intel was usually at least one process generation ahead of competitors, and often more than that. With Moore's law still going at full tilt, that meant not only more transistors, but also faster transistors, completely overwhelming the architectural deficits.
> occasional superior alternatives but "often" is kinda silly
Hmm...just off the top of my head: Motorola 68K, MicroVAX, LSI-11, SPARC, AMD 29K, Power, RISC, MIPS, Transputer, Alpha, HP-PA, ARM for desktop, Motorola 88K, Fairchild Clipper, etc.
I'd be hard-pressed to name an architecture that wasn't superior to i386. But architecture did not matter. With Moore's law no longer also getting us faster transistors, it might matter again: https://rodneybrooks.com/the-end-of-moores-law/
Do you have any experience how it was to target the home market before PCs and Windows took over it?
Having the backing of industry/academia/hobbyists is no small feat, and I hope RISC-V can keep pushing further into the consumer market.
understanding the electricity and visualizing the magnetism and diverse waves and its interactivities; in order to detect as to the example of a bird landing on the high voltage wires and how the properties of the particles can be read as well as stored in plants etc. and how the materials are properly constructed in order to distort the assimilation necessary to start the machine ;
and then destroy the school logic as to algebra titles etc, in which it is part after the experiments to start organizing circuit logic; maybe something about the quality of the electricity by improving the components including rust and dusting etc. perhaps thus by sealing the components in the process of initializing the machine to verify the veracity of the circuits; some degree of upgradeable serial number in order to connect other parts, perhaps identifying a first problem of logic; - and perhaps the idealization of unique components like the Raspberry system-board? where volatile parts is taken as user Hard-Disk content being the logic of software?
so better focusing on the complexity required than the ultra-fast Quantum Computer processor? can be produced at higher levels for virtual realities; [?] Just Guess;
They're not asking if it would be nice to have, they're asking if it can be economically feasible now. If there isn't going to be a very large use case for open but inferior processors, a lot of money will be lost by anyone investing. That isn't a problem with software.
https://lwn.net/Articles/743716/
direct link https://www.parallella.org/wp-content/uploads/2017/01/hipeac...
https://web.archive.org/web/19991128065121/http://openip.org...
However, CPUs are that complex these days and require a lot of equipment around it to be produced. The way is IMO much harder to open IP than to open Source.
With open software you can read the code, compile it and run it << zero trust. With hardware you can read the spec, but must trust the implementation.
This whole debate feels eerily similar to the emergence of open source software into the public eye, back in the 90s.
Which given the CVE entries per day isn't necessarily true, in spite of pull requests being reviewed.
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.
Could you provide an example?
Also, I hope you're not posting that from an Intel machine ;)
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.
The FAA and its set of safety regulations are written into US law. That's why airplanes are trustworthy and safe: more safe than other countries on the average.
https://www.faa.gov/aircraft/safety/ https://www.faa.gov/regulations_policies/handbooks_manuals/a...
Or do you think the US just MAGICALLY gets high safety results through sheer determination? There are systems in place, and I think it is reasonable to suggest that we should start building a system for computer-chip processors.
Open Source is one possible proposal. I'm not sure what other proposals exist to ensure that the internals of chips aren't compromised.
Building a bridge is one of the most heavily regulated things in the USA.
For details, see: https://www.fhwa.dot.gov/bridge/nbis.cfm
Every single bridge in the USA is documented, listed, inspected and regulated. There's even an entire division of the US Military that helps out: The Army Corps of Engineers. So its multi-agency, multi-department, and even includes military service members.
Bridge Building might be the only thing more regulated than Airline safety in this country.
> because mechanical engineers design them to be safe.
Civil Engineer btw. Not Mechanical. And Civil Engineers need to pass a strict level of training and licensing to practice in the USA. Granted, this is on a State-by-State basis rather that on a national basis (like Bridge-building).
But its still a government regulation, even if its State-wide instead of Federal.
https://www.nspe.org/resources/licensure/how-get-licensed
All 50 states require 4-years of work experience before you earn the title of "Professional Engineer". And that's the title you need before you can lead something like a Bridge-building project.
Not only are bridges highly regulated, but the people who are allowed to build bridges are highly regulated, at both the State and Federal levels.
----------
Now I'm not saying we enforce the highest regulation standards upon our CPU manufacturers. I'm basically saying "Stop coming up with bad examples". The incredibly safe examples you have brought up so far (Airline safety and Bridge Building) are the result of years of Government regulation and laws.
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 were no safety regulations (and testing) for cars, except that so far bad processor security haven't killed as many people as far as we know.
Open IP is one way to help making sure the above stays true. There are certainly other avenues, but for security it seems to be the case that it's best handled in the open.
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
open also means making the software that creates the chips design open too, otherwise you'll just get leapfrogged by closed designs.
This could overcome being a few generations behind on fab tech, just have the exact silicon you need.
you could also design open mainboard design with multiple zif sockets, this would be very flexible, and maybe futureproof.
Firstly, let's assume you basically need a big company to opensource their existing IP because opensource is no where near where Intel is today. So let's look at the obvious choice: Intel has traditionally perceived itself to be a manufacturing company. It tries to produce as many chip widgets as possible and producing CPUs or SSDs or network chips is just their way of finding ways to sell their widgets. The core of their business is fabrication.
Now, the only companies they let use their foundries to produce other chips are almost exclusively companies that they end up buying (I'm looking at you Altera).
By open sourcing their CPU designs they are practically guaranteeing that some of the chips they produce today would be produced by Samsung and TSMC. Try explaining to their share holders that you're giving away the crown jewels, damaging the core of the business and hoping for what....?
Secondly, taping out a chip is hundreds of thousands of dollars. Even if you did opensource everything, the only people who could actually produce the chip would be huge corporations, and the process of taping out isn't "Let's save it to a floppy and send it off". All of the tape out process requires proprietary tools from the fab, which are only available to the serious customers. So your source might be open but no one outside the company would be able to actually read them. And this is non-trivial, TSMC consider their tools to be a core part of the IP that differentiates them, they'll never release them under anything but a very strict contract to a client.
Finally, one of the key benefits to opensource is that you can fix something yourself, you can contribute and change things. Well not in hardware. The best you can manage is to fix the problem in the next $X00k production run.
Laying all that aside: No one has actually described what benefits Open Source software has over closed source that we're trying to map to hardware? To me a key benefit of Open Source is that we don't depend on corporations as gatekeepers to fix things, well that isn't solved in hardware open source.
The problem is people don't want slow CPUs.
It's not. The board layout of the Arduino boards is open-source, as is the software around them, but the microcontroller on them is not.
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 JVM and docker for the CPU and lead to another round of madness.
There is no harm in having alternate architectures. But putting everything up on GitHub is a recipe for disaster.
But if you're talking about distros (or some vauge distro-like prepackaged blob of Linux + userspace), it does happen. There are a lot of specialized Linux distros out there, and they aren't all on long-term support with security backporting.
The reason why this does not happen with Linux kernel is because Redhat and Canonical go to great lengths to backport kernel patches, which by proxy affect all the distos based on them. Also because Linux desktop is not big enough for OEM's of the majority of PC users to care about.
Android is a flavour of linux that went big. The fact that OEM's can clone the kernel and put their own drivers into it without being forced to update is what causes the most grief in Android world.
That's the opposite of "open".
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.
It's called Qualcomm.
I was replying to the parent using the word "disaster"
What you describe is the current state of affairs for CPUs. Intel, AMD, ARM, and every other company working in this space already "put all of their stupidity inside it in the name of features and security". These companies will continue to "put all of their stupidity inside" their products as long as innovation continues.
As Spectre and Meltdown demonstrated, bugs like these occurred in almost every CPU that allows speculative execution. Open projects will simply address these bugs as they are discovered just as private companies do for their proprietary design. Openness is orthogonal to this class of bugs.
> The entire time of kernel devs will be spent working around the various 'features' of the OEM designs.
No they wont. If a CPU spec is implemented by a large number of vendors, kernel devs will (must?) treat their support as they treat peripherals: They will provide support for the baseline CPU as is described in the open spec. Additional support is supplied either by the manufacturer or by volunteers who want to take advantage of additional features.
> But putting everything up on GitHub is a recipe for disaster.
I'll gladly take fragmentation if it means that we are no longer forced to accept ME, PSP, or TrustZone. Competition and diversity is a good thing. It's having only closed CPUs that's the recipe for disaster.
Anyway, your points are certainly valid. However, they are not a "will happen", but rather a "may happen". In FOSS, it took some time too, to find a working governing structure for large projects. A respected BDFL seems to help. Who knows what would be the best set-up for hardware.
But it should certainly be tried.