Meltdown and Specter's vulnerability disclosure again attracted attention to hardware-level bugs. Much has been done to improve (still weak) the security of our software, but all in vain if the hardware fails. Processors in our systems are still mostly proprietary and have already presented a number of unpleasant surprises (for example, in the Intel Management Engine). Therefore, there is a natural question about switching to open-source hardware, as we did with our software. Such a transition is quite possible and gives a number of advantages, although it is not a panacea.

Given the complexity of modern processors and the fierce market where they are sold, their development on the principles of open-source may seem an unusual idea. But there are already serious initiatives in this area; so the idea of ​​a free CPU design is not just fantasy. A small study of the topic reveals several projects; although the following list is clearly not complete.

What to choose

Consider, for example, the OpenPOWER project, based on the POWER architecture. This is not a completely free project, unlike some others, but it is a good example of the joint development of processor architecture. Processors on (relatively) open architecture are already on sale. OpenPOWER focuses on server CPUs; they are unlikely to appear in your computer or smartphone in the near future.

Then, there is OpenSPARC , where Sun Microsystems has fully opened the architecture of the SPARC T1 and T2 processors. Several projects have attempted to use these architectures, but it is not yet clear whether anyone has succeeded. At the moment, the SPARC open architecture is already ten years old, and the future of SPARC is generally in doubt. Something interesting can happen if Oracle decides to open the architecture of modern processors, but waiting for this event with bated breath is also not the best idea.
')
OpenRISC - fully open processor architecture for embedded applications; they have one fully ready processor (OpenRISC 1000). Several commercial versions of OpenRISC 1000 have been made, and there are reference implementations (such as mor1kx ). The Linux kernel supports OpenRISC with version 3.1, which was released in 2011, and the port on Debian has existed since 2014. True, work within the Debian distribution has ceased in 2016 . Work on the OpenRISC code for the kernel also slowed down, although in 2017 there was support for SMP . Overall, OpenRISC seems to have lost most of the development dynamics that it was before.

Now the maximum activity seems to be related to the architecture of RISC-V . This project focuses mainly on the instruction set architecture (ISA), rather than on specific implementations, but there are examples of free equipment design. Western Digital recently announced that it will use RISC-V processors in its storage equipment - this could lead to deliveries of RISC-V on a billionth scale. There is a set of development tools for those who want to play around with this processor, and many core architectures are available.

Unlike OpenRISC, RISC-V targets various uses. It is hoped that the simple RISC architecture will make it relatively easy to make a fast processor. At the same time, for low-end devices, there is an abbreviated command flow format, which reduces memory requirements and reduces power consumption. ISA provides extensions for specific implementations, which facilitates experimentation and the addition of hardware acceleration techniques.

RISC-V support in Linux has appeared quite recently; only in version 4.15 (release took place on January 28, 2018). Developer activity seems to be very turbulent, and the relevant projects also have support for the necessary tools and libraries. Apparently, the RISC-V has some support in the commercial industry — at least many companies have joined the RISC-V Foundation. In the near future, this architecture should continue to develop.

Solving a hardware problem?

After the release of information about Meltdown and Specter, the RISC-V Foundation published a press release promoting its processor architecture as a safer alternative. RISC-V processors are not really affected by these vulnerabilities because they respectably do not allow any speculative memory access. But the press release says that the benefits of RISC-V extend beyond these specific vulnerabilities. The very openness of the development model allows you to quickly implement the best security ideas from a wide range of developers.

It is becoming increasingly obvious that although Linux may have won the battle at the kernel level, there is a whole layer of proprietary hardware and software running below this level - and we do not control it. Therefore, the open architecture of RISC-V looks very attractive. Perhaps over time we will be able to partially regain this control. This seems to be a desirable dream, but to achieve it, it is necessary first of all to solve some problems.

The first of these, of course, is that although compilers can be obtained free of charge, this is impossible with regard to production capacity, especially expensive factories for the production of high-performance modern processors. If at the microchip manufacturing level, progress slows down - and some say that it is already happening - and production services will become more accessible for small customers, then experiments with processor architectures will become more accessible for more customers in practice. However, it will never be as simple and cheap as typing make in the console.

Until then, we will remain dependent on others in creating processors for us. This is not necessarily bad; almost all of us are just as dependent on others in creating software for us. But in the gland you need to achieve a higher level of trust. Getting reproducible software-level builds is a serious and urgent task; at the hardware level, it will become even more difficult. But if we do not achieve a certain way of checking the original architecture in a real iron sample, then we can never be sure, then a particular chip has that design, as we were told.

In the RISC-V specifications, nothing is said that specific implementations are required to openly open their architecture. Even if RISC-V succeeds in the market, there are high chances that real processors will not come with a freely licensed design. Large customers (who build data centers on their own projects) may insist on obtaining design chips - or simply create their own - but the rest have a rather weak negotiating position.

Finally, even if we get completely open and free processors, vulnerabilities at this level will not be completely over. We have a free kernel, but vulnerabilities in the kernel are also constantly found. Open iron can give more confidence that we will maintain control over our systems in the long run, but this is not a magic wand to solve all problems.

However, none of this should prevent us from achieving greater openness and freedom in terms of hardware. Once upon a time, creating a free operating system seemed an overwhelmingly difficult task, but we did it several times. Moving away from proprietary hardware design might be one of the best chances to preserve our freedom; it would be foolish not to try to do it.