Security Concerns Weigh Down Open-Source EDA

Open-source EDA tools are free, readily available, and growing in numbers, but many chipmakers are wary of using them due to security concerns.

On the plus side, proponents say these tools can help attract fresh new talent to chip design. Yet despite their spread online — GitHub alone has more than 140 EDA-specific repositories — using visible source code can provide new avenues of attack for bad actors. And in the context of tens of millions of dollars of NRE and the integration of increasingly heterogeneous design elements, the up-front cost of tools is not always the most important consideration.

“There are arguments in favor of open-source EDA tool sets,” said Mike Borza, principal security technologist at Synopsys. “Some of the open-source EDA tools are quite good, but some still have a long way to go. The issues there are the same kinds of things you see in other types of open-source software. Who are the contributors to the open-source tools? Are they adding things that are potentially generating Trojans in the RTL? Are there unintentional vulnerabilities? Are those unintentional vulnerabilities inserted by the tools, and are those being found by the people in the review process? The answer is uneven, like open-source software.”

Vulnerabilities in open source tools
While open-source EDA tools have clear uses in academia and hobbyist circles, they also have gained some traction in the commercial IC design world, according to Andrew Kahng, a distinguished professor of computer science and engineering at UC San Diego. “There are multiple tools that have, in my opinion, reached a critical level of uptake,” Kahng said. “I am most familiar with OpenROAD, but Verilator, KLayout, Yosys/ABC, gdsfactory, and others have had significant adoption in industry.”

What actually constitutes adoption is open to interpretation, however. “There is not a single product that does not include some amount of open-source tooling as part of the product,” said Chris Harrold, program director, developer tools at Ansys. “The most popular front-end rendering tools, the most common data layers, a ton of basic font libraries, even something as commonplace as network protocol drivers — a vast majority of these are based on, contain, or are themselves open-source code. In EDA in particular, open-source layout and design tools have been around for a long time, and are so prominent in the ecosystem that including bits of them in a product just becomes a matter of compatibility and meeting user expectations.”

That ubiquity brings its own set of issues. “If somebody contributes a piece of code that hasn’t been tested, they could be introducing any number of significant vulnerability flaws just based upon the ease of modification of the tool,” said Jim Montgomery, principal solution architect at TXOne Networks. “You’re just adding code, so unless it’s examined it may go unnoticed.”

Given the stakes at play in a multi-billion dollar industry, it’s not surprising that security is an open concern to those working with some of the biggest players. But even on a smaller scale, those in charge say they have taken extensive steps to ensure their tools are not open to attack, despite the source code being open to all.

Mohamed Kassem, co-founder and CTO of eFabless, strongly advocates open-source EDA tools. While some of the company’s more expensive offerings include access to tools from companies like Synopsys, eFabless designs largely depend on open-source tools. “There’s no one that can put something in our flow that is not approved by us,” he said. “In order to be approved by us, we have a scrutiny automation system that has multiple layers. Whatever your code is, it’s not going to break anything else. The beauty of open source is that transparency.”

eFabless’ open-source tools are available on GitHub, which Kassem said acts as a “baseline” for monitoring changes to the source code, allowing the company to maintain a log of who altered the code and what was done. “If someone wants to suggest a change, they have to submit a pull request. It only can get into our mainstream if we approve it with a certain set of criteria, including who’s submitting,” he said.

While Kassem touts the measures in place to ensure that all alterations to the tools’ code don’t just undergo security checks from the community but get verification from the company itself, not all open-source tools undergo that same level of scrutiny. Synopsys’ Borza pointed to a vulnerability constructed by a malicious actor in a Linux utility xz library as an example.

“Sometimes people examine the security of the products and are looking for what the issues related to that are,” said Borza. “In other cases, the tools don’t get very much scrutiny, so they are potentially doing things you don’t know. In the open-source software world, we saw an attack this year that was a multi-year attack, quite sophisticated, but also in some ways quite ham-fisted, in which somebody with malicious intent recognized the importance of a certain library. They started to work as a contributor, and basically forced their way into the contributors circle of that library. Eventually they started to put in things in the code that people were puzzling over. They realized that what this person was doing was inserting vulnerabilities into that code that were then being used in system libraries of open-source operating systems to create back doors.”

EDA tools are not generally directly exposed to the outside, so a security risk arising from publicly visible source code is less of an issue. “EDA tools run either on the desktop or in a cloud container,” Kahng said. “Because the designs and design enablements like PDKs, libraries, IP blocks, etc., on which the tools are run must be kept confidential anyway, the entire design environment is not exposed. It should be noted that proprietary EDA is not especially hardened either for the same reason.”

If open-source tools do present a problem at the EDA level, that could be due to the wrong users having access. If that’s the case, it’s a sign of a far greater institutional involvement, Ansys’ Harrold noted.

“An attacker could run a lot of simulation jobs using our open-source tools, which might be disruptive but not fatal,” Harrold said. “It is possible that they may be able to collect our customer’s data through a system that contains that particular IP, such as a layout or design file. However, if an attacker has the level of access to submit simulation jobs against your environment or read your models, then frankly you have much more significant risks in your environment than open source.”

Chips themselves are secure
While open-source EDA tools may be open to attack because of the transparency inherent in the tools, such as in cases like the attempted Linux hack, they also could be used to find vulnerabilities in the chips they are used to design.

“You can introduce any number of vulnerabilities,” Mongomery said. “Again, it’s open source. It’s freely available to contribute and modify the code on them.”

Kahng disagrees. He contends that if the hardware is designed in a system that meets certain parameters, any security flaws would not specifically be a result of the EDA tools.

“If (A) the design is closed-source, and (B) the design is ‘compiled into a chip’ with open-source EDA tools, but (C) this takes place in a closed, secure machine environment, then open-source EDA tools do not add any security risk,” he said. “Hardware is only as secure as the software used to create it. Software is only as secure as the rigor used to inspect it. The code used to secure the internet and banking transactions is open-source for a reason. Open-source EDA also allows for the highest level of security by allowing the code to be inspected by the world’s experts, who can ensure there is nothing in it which could insert a Trojan or other exploit into a hardware design.”

Even if that were not the case, Harrold noted that when open-source tools are used by designers in major company environments, there are enough measures in place to ensure that any back doors are caught and closed. “With open-source you also have the responsibility to provide a deeper level of due diligence because the impacts aren’t just in the code,” he said. “All of our products that use open source require those tools to undergo extensive review and approval prior to consumption. We have a dedicated team that is responsible solely for managing our use of open-source, validating the tools, and identifying any risks. This includes our own PyAnsys tools, as well as tools we consume in our products. Our process includes identifying the potential issues with the code and licensing and distribution to make sure that our customers can use our products and open source without introducing additional risks from it. Many people do not realize that open-source licenses can be just as big a risk as the tools themselves.”

He noted that the link between an open-source tool to the resulting product is often very small, resulting in an extremely limited attack vector. “This is also not to say that open-source software is inherently insecure — far from it, in fact. The vast majority of open-source tools strive to make sure they remain secure, as failing to do so risks their community goodwill. That is fatal for open-source tools.”

Conclusion
While opinions will continue to differ regarding open-source EDA tools, it’s important to put these differences in the context of where and how chips developed using these tools will be used, how much open source software is involved, and who has contributed to that software.

Even chips developed with commercial and proprietary tools can be vulnerable to attacks, and some chips developed with open-source tools may be as secure as anything on the market. But it’s the unknowns that leave some engineering teams uneasy, particularly with chips that may end up in safety-critical or mission-critical applications.

Despite that, the use of open-source EDA software continues to widen, whether as separate tools or code that is embedded into commercial or proprietary tools. Ansys’ Harrold noted that as with any new software, that comes with inherent challenges, and security has to be one of them. “In the main, however, this is likely a bit of a red herring in this context, since we are talking about closed tools running on closed platforms in closed environments with only a thin layer of interfaces leveraging open-source tools for their creation,” he said. “The open-source tooling is more about providing ways for the consumer to build their own interfaces that enable a better experience for them. As an example, from our tools, PyAnsys does not create an additional security risk in practice where customers are building custom UI/UX experiences, because you still require a level of access to interface to the underlying system. While new security issues will emerge in new environments, the general rule of systems is that these arise more from misuse or lack of security awareness than a fundamental flaw in the underlying code.”

eFabless’ Kassem believes open-source tools are making the EDA environment more secure, rather than less secure. “I believe that the best people in something are out there. When you give the community the capability to do this, and have some reasonable governance, you’re not sitting and just letting everybody play. We have strong governance, we don’t mess with that. Now, is there a chance that somebody’s going to mess with this? There’s nothing that can be called bulletproof, and that’s been proven even in private systems.”

Related Reading
As EDA Processes Becomes More Secure, So Do Chips
Researchers and engineers are working on increasingly secure processes in the EDA workflow, but they add to the cost.
Chip Security Now Depends On Widening Supply Chain
How tighter HW-SW integration and increasing government involvement are changing the security landscape for chips and systems.