I'm just surprised that the URL is still valid after 12 years!
IIRC this behaviour is now documented in the official manuals as "by design" since it was like that since the P3.
incredible how I (we) ran on buggy hardware for so long.
We should fund a tiny group for sane cpu design.
One simple example is the zero-bit. I don't have time to look up the exact details now, but IIRC, it's a simple hardware bit-flag that is part of the metadata of any value that can be read. If set, reading out that value returns zero. If not, it returns the actual value.
Data defaults to having the zero-bit set, and the only way to unset a zero bit is writing new data into whatever you want to read from. The exact mechanism is probably a bit different, but that's how I remember it.
Regardless of what the precise implementation is, the point is that by adding some smart hardware-based metadata like this in the form of bit-wise flags, you don't have to worry about having to manually wipe the data in memory once you are done with it (and have the speed benefits of not having to do so as well), yet still get all the safety benefits of never having to worry about buffer overflows and whatnot again.
It's happened, again and again. The ARM CPUs powering your phones are a good example. Maybe with more of a market, POWER9 prices might come down.
They are saner but the problem is still here
In truth you're correct, and ARM is sort of an unruly mess at this point, but that's a much larger discussion.
I know nothing about low level programming, and I'm wondering if webassembly couldn't be a good place to start designing CPU instruction sets?
Can someone more competent on the matter tell me if this idea is crazy?
Yes, it's crazy. :)
But seriously, the ISA (instruction set architecture) is not the problem, but the optimizations (deep pipelines and speculative execution, etc.) are.
>As I said before, hiding in this list are 20-30 bugs that cannot be
worked around by operating systems, and will be potentially
exploitable. I would bet a lot of money that at least 2-3 of them are.
AFAICT, de Raadt was concerned about Intel in general, but not the recent exploits in particular. We can find endless criticisms of every major company from the last 10 years (including on HN!); picking this one mailing list posting is bit arbitrary in the context of these exploits, even if de Raadt makes some good general points.
Looking back, I should have asked him how intel evaluates security risks considering how much of modern day computing uses it (which makes it an extremely valuable black hack exploit since it can work on practically every computer).
> It is not just buggy, but Intel has gone further and defined "new ways to handle page tables" (see page 58).
The MMU, page tables, and TLB are all directly related.
That wasn't my intent at all. de Raadt makes good, generally applicable points.
How do you explain the following:
> These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will ASSUREDLY be
exploitable from userland code.
> Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare
the hell out of us.
> AI90 is exploitable on some operating systems (but not
OpenBSD running default binaries).
Plus huge development effort in stack/address randomization, W^X pages, dynamic kernel and c library relinking, etc as simply 'concern about intel in general' but not any details 'in particular'?
Even if the stated position is not true, it would be logically inconsistent to assume someone whose operating system project focuses on 'security and correctness' to simply be making general statements and not being concerned with actual low-level details..
What you said:
> but not any details 'in particular'?
Looking at the list of items Theo gave, most of them were fixed previously, and the others, at least to my largely uneducated eye, do not appear to be related to this specific issue.
Unless I am mistaken (and that's certainly possible!) it was not at all related to Spectre/Meltdown
> Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us.
I believe that Intel didn't believe that these bugs suggest a fundamental issue that can be exploited, until Google Project Zero created a working exploit.
Given that we know that intelligence agencies have asked for backdoors before, in both hardware and encryption standards, do not interpret my post here as a claim that they would never ever even think of asking for plausibly-deniable CPU bugs to be inserted into hardware. I am just saying that Occam's Razor says we should prefer the perfectly plausible scenario I gave above where they do not have direct involvement in these bugs, not because of their pristine ethics, but because given the circumstances on the ground, actively intervening is not their best choice from their point of view using their valuation function, when they can attain all their goals without active intervention.
(I'm willing to believe in things that might be labelled "conspiracy theories"; history is rife with proof that they have existed in the past, such as the aforementioned cases where we know backdoors have been inserted into crypto standards, as well as other things such as the way in which the Soviet Union was created which essentially involved what was initially a small conspiracy, and I see no reason to believe they have ceased in the modern times. But I want to see how the conspiracy theory passes Occam's Razor; many of the conspiracy-minded, in my opinion, underestimate the randomness and everything-is-always-correlated-a-bit-ness of the real world.)
Why ask for a bug when you can just sit back and wait for them?
Yes, I'm kidding about the first part.
Since neither the threat nor the reality of PR disasters has ever given the NSA pause before, occam's razor strongly suggests this theory of yours is wrong.
I would also disagree that your assessment is correct anyhow; they are insensitive to certain kinds of bad PR, but not generally immune to it, nor do they act generally immune to it. The people in charge of funding the intelligence community may not come after them for getting caught putting backdoors in things; indeed, this may even prove to the people controlling the purse that they are doing their job. But they are certainly sensitive to ensuring that the people controlling the purse do not come off looking bad, and as a part of that, sensitive to not getting caught conducting open, unambiguous acts of war against every nation in the world. We all "know" that they do, everybody else "knows" that they do, and everybody also "knows" that you shouldn't trust Chinese-manufactured electronics either for the same reason, but it's still not openly known. The distinction between open secrets and openly-known facts may greatly confuse Spock and he may shake his head about how illogical it is for everyone to know a thing and for everybody to know everybody else knows but still act as if nobody knows, but is an integral element of understanding human politics, in which appearances matter a lot.
Their mission isn't to make everything less secure, it's to make the other team's stuff less secure (where "other team" includes the citizens of the US apparently).
Furthermore, given the number of bugs in just about every piece of software (including kernels), I don't think these bugs are even an anomaly that needs an explanation. Bugs exist in every complex system, and CPUs are very complex these days.
That said, to address your direct question of "would it be possible", I'm fairly sure it would; we have hints from Linus that Three Letter Agencies have asked him for backdoors, so I'm sure large hardware companies have open channels with the NSA et. al. as well.
Not really. It's not like stuff like that Dual_EC_DRBG were export only, and IIRC, they did hold on to zero days that would affect American systems, leaving those system vulnerable, while they exploited them elsewhere.
What is likely is that security agencies with their larger staffs and budgets do discover many of them before the private sector. It's certainly plausible that the NSA knew about this new class of attacks before we did.
BTW -- forget about CPUs. My biggest concern is with the chips that get less security attention: GPUs, network chips, USB controllers, etc. Those are likely just as bug-ridden or more.
I also wonder if one or more security agencies find a lot of their efficacy in just a small handful of exploits. And if those were to be patched, they'd find themselves severely hamstrung. So seen as a threat to national security, they have a strong need to ensure the availability of exploits.
Is there any discussion? I thought OpenBSD development mostly took place on public mailing lists ?
The entire Internet is wide open, the holes just aren't known yet.
But those aren't the issues that were exploited. His post has absolutely nothing to do with the current issues. It's just uninformed dogpiling (the ignorance of the crowd).
All chips have errata. This post is not particularly informative or relevant to anything.
He was less prescient when he implied that it would take Intel a year or two to get beyond this.
> For instance, AI90 is exploitable on some operating systems (but not OpenBSD running default binaries).
if you know how the processor and OS behaves at a low level, and read specific hardware errata which you know will cause problems that logically cannot be worked around, developing a proof of concept (aka 'discovering') is simply a waste of time and effort..
"(While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too)."
Glad to see that in 2018 AMD's reputation has generally improved from this.
Maybe loading data speculatively across a protection boundary was careless. It seems besides the latest ARM CPUs no other vendor went that route. But not owning up to it and issuing PR statements saying "This works as designed, not a bug" is a bit hard to stomach.
But if it needs help drafting a better PR release, someone is welcome to point them to HN's comments section.
What a reductive and shortsighted evaluation of the situation.
Can they handle the loss of faith from big companies? Can they handle the loss of faith from the entire tech community? Seems to me that AMD et al have now got the perfect opportunity to erode intels market share and build up a large market base amongst cloud providers etc (not to mention security minded users) that require technology that is both resistant to meltdown and not underperforming hardware.
It's silly to act like this is a storm in a teacup because the HN community is up in arms over it. Monopolies fall, and the loss of trust and key clients tends to precipitate that fall.
>But if it needs help drafting a better PR release, someone is welcome to point them to HN's comments section.
Their PR was shocking, but on the order of things people are upset about over this incident, this is literally at the bottom.
It was a tongue-in-cheek response to OPs statement that we should feel bad for Intel and offer it help. I suggested that it needs help drafting a better PR release that's a bit more honest and straightforward.
> Can they handle the loss of faith from big companies?
With a $200B capitalization they certainly can.
> Seems to me that AMD et al have now got the perfect opportunity to erode
Agreed. The next step is to see if any of the large cloud providers or PC manufacturers will announce they are buying AMD CPUs. I hope because I'd like to be able to buy cheaper CPUs and have more competitors in the market. But realistically I kind of doubt it. At the end of the day INTC's stock hasn't moved that much. The performance hit as reported by Google didn't seem to as big.
nor should it.. huge stock (so less speculators), many products besides x86 PC processors, and their reaction/fix to this & subsequent impact to actual earnings hasn't shaken out..
not pro or against intel. but mentioning this as concerns market stuffs.
Wow I'm surprised this is even legal because it sounds like an implemented monopoly.
Let's wait to see how much performance is lost and what vulnerabilities get used in the wild.
"We translated Intel's attempt to spin its way out of CPU security bug PR nightmare as Linus Torvalds lets rip on Chipzilla"
But it couldn't be better timing for ARM. AMD isn't the competition (Though this helps them a little bit) it really is all about ARM and it is going to get a lot more attension with this. Windows runs on ARM now.
CPUs can't get much smaller. It is now how many cores and thermal control you can place on a waffer. ARM has the advantage in both of those. We just have to learn how to utilize multiple cores better than we are now.
I can’t say anything about ARM vendors, but I’m pretty familiar with MIPS and PowerPC errata from chips in the mid-2000s and they generally made Intel look 10x as professional and careful.
* http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect... https://news.ycombinator.com/item?id=16064545 (https://newsroom.intel.com/news/intel-responds-to-security-r...)
* https://news.ycombinator.com/item?id=16072368 (https://newsroom.intel.com/news-releases/intel-issues-update...)
* https://news.ycombinator.com/item?id=16067245 (https://www.amd.com/en/corporate/speculative-execution)
* https://news.ycombinator.com/item?id=16068118 (https://developer.arm.com/support/security-update)
* https://news.ycombinator.com/item?id=16072912 (http://blog.dustinkirkland.com/2018/01/ubuntu-updates-for-me...)
* https://news.ycombinator.com/item?id=16071769 (https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...)
* No headline, although mentioned at https://news.ycombinator.com/item?id=16074531 and elsewhere (https://www.freebsd.org/news/newsflash.html#event20180104:01)
* https://news.ycombinator.com/item?id=16076660 (https://support.microsoft.com/en-gb/help/4072699/important-i... https://support.microsoft.com/en-gb/help/4072698/windows-ser... )
* https://news.ycombinator.com/item?id=16075348 (https://support.apple.com/en-gb/HT208394)
* https://news.ycombinator.com/item?id=16076175 (https://lists.debian.org/debian-security-announce/2018/msg00...)
* https://news.ycombinator.com/item?id=16076328 (https://lists.opensuse.org/opensuse-updates/2018-01/msg00000...)
On the other hand, Intel's stock price did recover in response, reversing the somewhat panicked or speculative drop earlier in the day, so perhaps this was mainly for the market.
What leads you to believe that Intel has any reason to think that there's an issue that needs changed? Or that "the community" knows anything about their business processes or what Intel should do? They have their highly-paid C-levels to figure that out.
From their perspective, there's no problem. Nothing needs fixin'. You'll keep buying their CPUs, anyways -- you don't really have much of a choice, do you? 
Just go install those updates from your vendor(s) and go about your business, you'll be fine. No big deal, nothing to worry about. Carry on. Just like you did with that recent little ME/AMT issue. There'll be another issue to deal with in a few days and everyone will forget all about this one.
: Oh, you're gonna replace all your infrastructure with AMD's CPUs, huh? Yeah, sure you are. They're no different.
2) Cache invalidation and
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery
There's two hard problems in computer science: we only have one joke and it's not funny.
* naming things
* cache invalidation
* off by one errors
> A cryptic message from Bond's past, sends him on a trail to uncover a sinister organization. While M battles political forces to keep the Secret Service alive, Bond peels back the layers of deceit to reveal the terrible truth behind S.P.E.C.T.R.E.
Catchy, on point pop-culturally and ominous.
Your comment is disingenuous and dangerous.
I never said that opensource software is not affected, I said "not being affected as a user". Because opensource software, being peer-reviewed, will never try to exploit a CPU bug. Opensource software is, by default, non-malicious.
So is closed source software.
You seem to be deeply confused about the scenarios people are worried about.
All the open source in the world doesn't help in either scenario.
You're focused on someone deliberately running a malicious program. But if they do that, these exploits aren't even necessary to do severe harm. It's a marginal scenario at best.
Sorry what? 99.999999% of all the malware that exists and has existed today, is/was closed source. Compare that to the other 0.0000001% that got once or twice into opensource and was removed as soon as it got detected.
I've never talked about (1), of course my comment was not targetted to server owners but by normal workstation owners that only have one user.
There is plenty of open-source malware, and most closed source software is not malware.
You seem to be conflating "is in a trusted open source distribution, listed as non-malware" with mere "open source". Code that is openly malicious, or has never been peer-reviewed, is still perfectly capable of being open source.
> I've never talked about (1), of course my comment was not targetted to server owners but by normal workstation owners that only have one user.
That's cool but the workstation use case is not why people are freaking out. The workstation is the place where you don't even need this bug to take over and ruin everything, because it's all under one account anyway.
Saying it's a "way to not be affected by these bugs" is pretty myopic.
If the FOSS world had software that worked for everyone, people would use it. Right now, the only major group this is true for however, are developers. Until this changes there will be no 'year of the Linux Desktop' or whatever.
Firstly not all security issues involve installing 'malware'. Take heartbleed; a major security vulnerability in open source software. To be hit by that you didn't need to install any non-open source software. You could have had the most pure and open stack of software and hardware ever created and it would have made no difference because the flaw was an information leak that didn't involve installing software or even unintended remote execution of code. That bug was due to the existing already installed open source code copying past the end of a buffer. Similar information leaking bugs could feasibly exist due to CPU bugs or compiler bugs or undefined behaviour in the code etc (i.e. all sorts of ways that don't involve installing malware and aren't even obvious from reading the code).
Secondly, even exploits that do involve "running malware" are very often not because the user intentionally installed malware. They happen because the user did something like download and decode an image file which took advantage of a vulnerability in their (open source!) image decoding library to execute code on their machine. Again in this scenario it doesn't matter that the user would only ever intentionally install open source software, because the malware was executed unintentionally when they performed an activity they didn't expect to lead to code execution (viewing an image).