Intel-imposed secrecy still surrounds many details of the vulnerabilities Meltdown and Specter which caused and continue to cause problems at a global level.
It is known that information for security vulnerabilities that are discovered are kept strictly confidential until a new patch is released. It is a mature and well understood process.
But in the case of Meltdown and Specter, things did not go as expected.
"Normally, we have schedules and we fully disclose what happened," said Jonathan Corbet, who maintains documentation for the Linux kernel and is a member of the Linux Foundation's Technical Advisory Board.
"In this case, there is still a lot of secrecy about Meltdown and Specter and how they can be managed."
Jess Frazelle, who works on open source software and containers for Linux at Microsoft told linux.conf.au open-source software conference held in Sydney on Wednesday:
"There are people who have publicly stated at this conference that they are not even allowed to name these vulnerabilities," Corbett said, referring to Intel's Casey Schaufler.
Schaufler presented a debate about the future of security at the Linux kernel, but he was forbidden to report even the most important problem with his company's products from the bug Pentium FDIV which was a generation ago.
Could vulnerabilities such as Meltdown and Specter be detected faster if manufacturers move to more open architectures, projects that could be repaired more directly by software communities?
Hardware hacker Andrew "bunnie" Huang believes this:
"Unfortunately, I think in the case of this particular error, all the components that were necessary for it to happen were published," but he is generally convinced that open hardware can help find other errors.
But the problem is purely profit:
Huang said it would be interesting to see what is happening with Intel, as the Pentium FDIV error cost them 475 million dollars 1994.
On the other hand, Huang wondered if this secrecy eventually helped.
“From whom are you trying to protect the entrance? Are you trying to make sure that random young scripters do not use vulnerabilities? Or are you looking to keep the state ones hackers away; .. If you're really trying to protect against, say, government hackers, those guys might already be listening in on your communications and would know about the vulnerability the same time you did.”
