Home / Others / The fusion and response of the Spectrum are hampered by the secret of the & # 39; exclusive club & # 39;

The fusion and response of the Spectrum are hampered by the secret of the & # 39; exclusive club & # 39;

The secrecy that still surrounds many details of the Meltdown and Specter vulnerabilities caused problems and continues to cause problems, according to speakers at the open source software conference linux.conf.au in Sydney on Thursday.

Newly discovered software security vulnerabilities are usually kept under embargo until a solution is ready for distribution. It is a mature and well understood process. But in the case of these hardware vulnerabilities, things did not work as well.

"Normally, when an embargo ends, we get timelines, and we get almost a full disclosure of what happened," said Jonathan Corbet, who maintains the documentation for the Linux kernel, and is a member of the Foundation's Technical Advisory Board. Linux

"In this case, there is still a lot of secrecy about what happened with Meltdown and Specter, and how they were handled, and what exactly was happening in the three months or so between the initial revelation [and] when the kernel community of Linux started hearing about it, "he said.

"We really have disclosure mechanisms within the community that have solved a number of these problems, at least for most of the problems we have had, it's not perfect, but it works pretty well." Those mechanisms were not used this time This disclosure process was handled very differently, why, I do not really have an answer to that.

Jess Frazelle, who works on open source software, containers and Linux at Microsoft, was even more taciturn, although like all panelists, she was speaking in a personal capacity.

"I think maybe it's a way to fix it in the future, obviously I would not have an absolute demonstration of an embargo," Frazelle said.

Part of the secrecy has been surreal, even Kafkaesque.

"There are people who have said publicly in this conference that they were not even allowed to say the names of these vulnerabilities," Corbet said, referring to Casey Schaufler of Intel.

Schaufler presented a session on the future of security in the Linux kernel, but it was banned even mentioning the most important problem in the products of his company since the Pentium FDIV error a generation ago.

"I would like to see the end of that," Corbet said. "I would like the industry to finish at least that part, so that we can get the whole story afloat and discover how to improve next time."

Katie McLaughlin is the site's reliability engineer for Divio, a Django and Python-based cloud hosting service based in Zürich. Despite being a second-tier cloud provider, he only heard about vulnerabilities when the information began to appear on Twitter.

"There seemed to be a kind of decision that some cloud providers know and others do not," McLaughlin said. The smaller providers in the cloud did not know anything, even though they actually paid for the hardware.

"I'm not sure exactly what happened there, but it seems to be an exclusive club as to whether or not you know, and it's not really clear what lines I should be informed about."

Corbet agreed. "I'd hate to see a world where only the largest cloud providers have access to information about something like this because, you know, that's competitive [issue]."

Benno Rice, a member of the core team at the FreeBSD operating system development community, said his developers had little warning.

"From the perspective of FreeBSD, our main complaint is that, despite having relationships with many of the suppliers involved, we did not discover it until very, very late in the piece," Rice said.

"We had, I think, 11 days between the time they told us, from when the embargo was stopped, to develop … the isolation of the table from the kernel page or something like that"

Rice said that he did not attribute the last warning to any malice, and laughingly said that he hoped it would be a once-in-a-lifetime event.

Read Now: Cybersecurity in 2018: A Roundup of Predictions

"It is the largest customers of Intel products that get the first Intel crashes and, as projects that do not have a supplier relationship specific with Intel, which puts us on a "do not know" list.

Even the Google kernel developers had trouble getting information, at least initially.

"Inside Google, even though it was pretty well contained, Not many people knew it, "said Kees Cook, a Linux kernel security engineer who works on Android and Chrome OS.

" When I discovered it, it was quite Constrained … Trying to make sure everyone who needed it knowing it went through an approval process to learn about it turned out to be somewhat difficult, "he said, although things improved after the initial problems.

" A lot of people talk about how the embargo was a complete tre. From my point of view, it seemed that the internal notification during the embargo was where most of the problem was. The embargo itself was relatively successful, and only broke six days earlier than it started in June of the previous year … I thought it was relatively successful, and the things that could be developed in view were developed outdoors, and That seemed to go pretty well. "

Is open hardware the answer?

Could vulnerabilities like Meltdown and Specter be detected more quickly if the processors moved to more open architectures, designs that could be more directly reviewed and influenced by the communities of software?

The hardware pirate based in Singapore Andrew "bunnie" Huang believes not.

"Unfortunately, I think that in the case of this particular error, all the ingredients that were necessary for this to happen they were publicly disclosed. We all know that speculative execution occurs. We all know that there are channels on the side of time [that can be used in attacks]"Huang said at the conference.

" One of my favorite quotes from [mainframe computing pioneer] Seymour Cray was that memory is like an orgasm. It's better if we do not have to pretend it. And every time you try to fake some performance, you're going to have a parallel channel of time, "he said.

Huang believes that open hardware could help find other types of errors, however. [19659002]" There's all a class of things that exploit hardware that have not yet been revealed, that are waiting to come out … All these things that you do not even know are inside the processors, you would be able to find, and review, and be like, & # 39; sacred cow that is really frightening & # 39; "

According to Cook, Meltdown and Specter highlight the need to pay attention to the most paranoid people.

See also: Specter slows the need for CPU speed

" We understand the timing side channels for a long time, but there was not a practical attack that we could consider as use, "Cook said," maybe I'm not smart enough to find the practical attack, but I could still be there. "Someone else might have found it.

The problem, of course, is that end users will continue to demand better performance.

As Huang said: "It is an arms race to arrive very quickly, and the thing that was exploited was, you know, something that was involved in achieving good performance on those devices."

Speculative execution was a concept integrated into the design, and that concept turned out to be flawed. Huang said that it would be interesting to see how this develops for Intel, because the Pentium FDIV error cost them $ 475 million in 1994.

"It can be scaled up to what it might look like for Intel now," Huang said.

Huang believes that fear of such massive payments could dissuade sellers from switching to more open designs.

"The answer will be in terms of, well, this is the reason why we should keep everything closed, because it is very expensive if you find out about our mistakes that we send in our hardware that has been there for years, years and years" , He said.

"It will be interesting to see how everything develops, and how that interacts with the chip designers and their kind of paranoid mentality about the exchange of documentation."

Huang also wonders if strict seizures really help.

"Who are you trying to protect against the embargo? Are you trying to make sure that random scripts do not use this? Or are you looking to prevent state actors from trying to exploit all the computers in the world? … Yes You really want to protect, for example, the state actors, it is possible that those guys are already listening to your communications, and they would have known the exploit at the same time that you would have known it, "Huang said

" Actually, simply open it to the whole community to solve the problem, and make us all join against state actors, would have been a much more powerful response, "he said.

"As a hardware engineer, it seems crazy to me that you think you can run secrets without secrets in the same piece of hardware."

Related coverage

Source link