>We asked repeatedly, but Intel provided no advance notice. We did not
even receive replies to our requests for dialogue.
Intel's treatment of *BSD is frankly quite insulting, especially so given that they serve a _huge_ portion of the internet traffic, with Netflix using FreeBSD for content delivery.
Certain parts of the BSD community keeps leaking stuff early, either by doing commits in public, or by talking about stuff in advance, before all the bits are in place to protect systems. Hell, they already leaked one this year, forcing a huge scramble all round to get patched out of the door. It has been a persistent issue for years. Why on earth would they still expect to be trusted?
It may well be just one or two people doing it, but their actions are screwing things up for an entire set of operating systems.
It's especially critical for coordination to happen on vulnerabilities like this one, where it requires a combination of microcode and kernel patches to be done in sync. If one distribution leaks early, all are put at nearly immediate significant risk.
These are bugs related to caching and thus unrelated to cpu architecture.
The core lesson appears to be that Intel has been playing loose with security. That is not a fundamental x86 problem, not so long as AMD is producing competent cpus.
HN mods: This is not a dupe! Also could whomever changed the title, please change it back? This specifically addresses these issues on Intel CPUs in relation to OpenBSD.
> We believe Intel cpus do almost no security checks up-front, but defer checks until instruction retire. As a result we believe similar issues will be coming in the future.
21 comments
[ 4.7 ms ] story [ 58.3 ms ] threadhttps://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/L1TF
https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html
Intel's treatment of *BSD is frankly quite insulting, especially so given that they serve a _huge_ portion of the internet traffic, with Netflix using FreeBSD for content delivery.
To be honest the attitude of "everything sucks and everything is broken" doesn't help OpenBSD though they are right to complain about some things.
Well, looking at all the chips I've bought in servers for the last 5 years, they are not wrong.
https://lists.freebsd.org/pipermail/freebsd-amd64/2011-March...
What's funny is that LWN, a Linux news outlet, might have:
It may well be just one or two people doing it, but their actions are screwing things up for an entire set of operating systems.
It's especially critical for coordination to happen on vulnerabilities like this one, where it requires a combination of microcode and kernel patches to be done in sync. If one distribution leaks early, all are put at nearly immediate significant risk.
Most ARM & MIPS CPUs just don't yet have the raw power people have come to expect.
The core lesson appears to be that Intel has been playing loose with security. That is not a fundamental x86 problem, not so long as AMD is producing competent cpus.
https://news.ycombinator.com/item?id=17759762
> We believe Intel cpus do almost no security checks up-front, but defer checks until instruction retire. As a result we believe similar issues will be coming in the future.