The most striking thing here is that Linus has apparently dismissed incompetence as a rational explanation. Yes, he is often brash, but usually he is accusing someone of sheer stupidity. He does not do that here. Linus alleges that we are being lied to - that we don’t know the full story, nor Intel’s motives.
Furthermore, we are left to wonder if Microsoft is also being fed “bullshit” patches, and if they may be less discerning than Linus regarding a proper solution.
He's quite clear about his theory as to Intel's motives:
> The whole IBRS_ALL feature to me very clearly says "Intel is not
serious about this, we'll have a ugly hack that will be so expensive
that we don't want to enable it by default, because that would look
bad in benchmarks".
> So instead they try to push the garbage down to us. And they are doing
it entirely wrong, even from a technical standpoint."
That bit sounds to me like Intel is trying to pull a "Volkswagen": have it perform better in benchmarks than in real life (when hopefully secure execution will be enabled).
More generally, an opt-in switch to disable unsafe behaviour expresses a clear intent to preserve the unsafe behaviour for the foreseeable future.
Disabling unsafe behaviour for good on current chips and removing it from future ones would be equally easy, and clearly it isn't Intel's intent.
Plausible reasons, apart from looking good in benchmarks, include ease of access for their three-letter friends and not bothering with the cost of designing safe and high performance processors.
I would hope that it would not be removed if there is a performance difference. Not all systems are multi user, thinking stuff like includeos or systems that can control their interaction such that the risk in very minimal and not worth the cost.
If it were removed, the new processors would simply be worth less than the ones that immediately preceded them. The systems you're thinking about would then cost less. What's the problem?
The problem, of course, is that vendors couldn't pretend to sell systems that are worth the prices they would have quoted before all of this awfulness was exposed. That would be a problem for the vendors only. The rest of us would be better off.
But that penalizes the single process systems, they exist. One already pays a cost of overhead for multiprocess/multiuser systems and this is part of it. Pay for what you use. But have sane defaults(protect the common case).
Then again, I cannot see this costing much in future chips.
This debate is about desktop and server processors. You are imagining there is a market segment, worth caring about for non-niche companies like Intel, of non-hackable systems with no network access that use high-end microprocessors, but it isn't so.
Most relatively complex systems that use deluxe microprocessors and could be air-gapped are accessible for convenience instead, and more extreme actually inaccessible systems are likely to use different, specialized processors.
Why do you exclude all single-purpose networked servers? e.g. why wouldn't it be reasonable tradeoff for a private compute cluster with a limited set of applications (or even just one), systems running really dumb services, ...?
On another forum somebody suggested laywer / legal reasons. That if default performance takes too big of a dive the case for lawsuits is stronger. They already have a class action filed against them. A benchmark performance dive would be one angle to use in court.
Coming to a court with "unclean hands" won't help their case either. And showing bad faith can really crank up the damages awarded if it's a jury trial.
The processor's security features should perform as described - anything less is a very nasty surprise waiting for users. Intel could allow users to opt-in to insecure behaviour for performance, but insecurity absolutely must be opt-in rather than opt-out.
"The processor should perform as described - anything less is a very nasty surprise waiting for users. Intel could allow users to opt-in to less performant behaviour for security, but bad performance absolutely must be opt-in rather than opt-out."
Take away: it all depends on the users preferences. I am with you, in most cases, it should be about security, but I guess there are legitimate use-cases for the opposite as well.
I do video crunching on internal systems, I'm happy that the code I run has nothing to gain from spectre or meltdown, but even a 10% drop in performance is bad, and sometimes can mean doubling the cost (if the cpu that was encoding two real time feeds is no longer powerful enough to do so without dropping frames)
Not every one runs a lamp stack on the intenet.
That said the default should be security. I have to opt in for "maximum performance" in the bios of my hp kit, rather than "balanced power and performance", why shouldn't I have to opt in to "faster but less secure"?
> "The processor should perform as described - anything less is a very nasty surprise waiting for users. Intel could allow users to opt-in to less performant behaviour for security, but bad performance absolutely must be opt-in rather than opt-out."
But that isn't true. Poor performance is not remotely in the same class of "very nasty surprise" that security model violations are.
Users can already choose. They can buy old processors without the fix.
I really don't see what case anyone could have against Intel if they just fixed this. Having a fix but turning it off by default seems far more dangerous from a legal perspective. Or having the processor perform far worse in reality than advertised.
Tell me where you could buy old processors in sufficient quantity today and please explain how a modern motherboard with sufficient RAM would hold such an old processor?
But if you want a processor without this fix, then you're in luck: from what I understand, all modern Intel processors don't have this fix yet. And they're very well supported by motherboards.
And by the time the current crop of processors becomes unavailable, I suspect newer processors will be much faster than anything currently available.
Yeah if you could point me towards instructions on how I can install this old processor I just bought in my Macbook that'd be great, also if you know how I can install this old processor in my AWS instances that'd be awesome too.
I winced as an owner of Volks Wagon stock when I read that. 3 people on this thread have now reacted to it.
If that type of behavior gets branded as "pulling a VW", that is the type of thing that could destroy VW in the long term. I agree it is a great analogy though.
The root question is what else is Intel trying to cover up with these garbage patches? Are they afraid of power leakage across gates allowing an attacker to gain a higher level of privilege in certain generations of silicon, and trying to cover it up with these patches (hence some of the seemingly crazy things they do)?
I could be very wrong but I read it as Intel trying to cover the fact that there are huge performance penalties with the patch enabled. Therefore Intel will continue to market chip performance sans patch while pushing down the responsibility of enabling them to OS vendors.
Not with those patches, since they haven't been merged yet. The performance decreases that have been reported so far are for Meltdown patches, those new patches are apparently meant to mitigate Spectre.
Probably not secret anymore. CMS (the "Code Morphing Software" that implemented the x86 emulation) originally went straight to translation which was difficult to get correct and was expensive to do for code that might only be run once. Linus, when he joined said "That's stupid" and wrote an x86 interpreter which then acted as the first tier in the emulation. That let to a massive improvement in quality as more workloads could be tested and enabled an awesome creation by Jim Mattson (IIRC): self-cosimulation. CMS could be run in a mode where all translation were cross checked with the interpreter before the results were committed.
This was before my time and I'm sure he did much more. I only have first-hand knowledge of his work on TVM, the Transmeta x86 Virtualization which predated Intel (and AMD's) hardware support for x86 virtualization. Sadly it never productized. I suspect we couldn't find a way to monetize it.
At least the journal reports I read at that time implied that much. He was one of the technical leads on this as far as I recall. So he would have had to get a very good knowledge of the Transmeta CPU and of the x86 instruction set for that task. I think it shows here.
Linus calls people stupid when they are usually being stupid, at least in his eyes. He doesn't wantonly accuse people of stupidity for no reason. It's just that when he perceives stupid activity... well, he generally goes off. It's his main trigger.
Wonder if perhaps Intel is under classified and gagged duress from the government? There has been plenty of evidence the government is not acting with citizen security foremost in its technical and telecommunications policies.
Hanlon's razor should include an exception where PR and politics are involved. Discounting malicious people as just stupid is the reason so many "stupid" people are in power.
>The most striking thing here is that Linus has apparently dismissed incompetence as a rational explanation. Yes, he is often brash, but usually he is accusing someone of sheer stupidity. He does not do that here. Linus alleges that we are being lied to - that we don’t know the full story, nor Intel’s motives.
"And that's actually ignoring the much _worse_ issue, namely that the
whole hardware interface is literally mis-designed by morons."
Maybe you missed this line? Some classic Linus right there...
The author misses one key point: it’s not only about debt coming due on their scheduled dates. It’s that much of this debt is also saddled with covenants that can cause a debt to be collectible at any time if the terms are not met. Things like a company's loan-to-value ratio, leveraged inventory through high accounts payable, and other financial metrics. In short, market troubles can force long-term lines of credit to abruptly come due.
It was my understanding that CoreOS was started as a minimal Linux distro tooled for hosting and orchestrating Docker containers. IMHO, Docker still has a long way to go to impress the security community.
Maybe, but in the meantime I can't imagine a scenario where such a direct financial threat to a business isn't vigorously defended by Symantec. I'm not a lawyer, but certainly they must be working to determine if they have a legal basis for seeking an injunction against Google. They could even be building some sort of legal theory based on tortious business interference, contending that Google is doing irreparable harm by trying to come between Symantec and the expectations of its paying customers.
To a large degree, the ongoing utility of Perl 6 depends upon the continued vibrancy of the CPAN community. IMHO, CPAN is anything but vibrant by today's standards.
While CPAN hosts a vast archive of nearly 35,000 modules[1], many are aging. Fewer than 800 modules are known to exist for Perl 6.[2]
> CPAN is anything but vibrant by today's standards.
I guess it depends on how you count it, but if you look at the actual statistics[1] the number of uploads, new authors is pretty much the same as when perl was in its heyday.
This isn't all old code churn either, from some brief clicking around new CPAN distributions in January peaked in 2005 at 251, whereas January 2017 saw 187[3].
Sure, Perl has been surpassed to a large extent proportional to other languages, but what tends to get forgotten in these comparison between language popularity is that even languages that have "fallen from grace" are comparatively going just as strong as they were 10 years ago, because computing has grown in the aggregate.
Which means that while your language of choice may not be as well known to your typical programmer as it was 10 years ago, the likelyhood of finding an existing module to perform some task is about the same.
> Perl 6 depends upon the continued vibrancy of the CPAN community.
Why do you say that? Is this a theoretical point, a reasonable conclusion based on reading about Perl 6, or something based on trying and failing to do something with Perl 6?
> IMHO, CPAN is anything but vibrant by today's standards.
Have you encountered problems that aren't being addressed? What do you make of the river cleanup effort[1] and the new metacpan?[2]
> many [CPAN modules] are aging.
Do you agree that "aging" that's due to modules continuing to work without needing to be changed (due to careful maintenance of backward compatibility and mass testing[3]) is actually a good thing even if it looks bad?
Do you agree that the same "aging" point can reasonably be made about the module archives of Python, Haskell, Fortran and Rust? If not, what is/are the key difference(s)?
> Fewer than 800 modules are known to exist for Perl 6.
Do you agree this might be a good sign, reflecting the "lots built in" aspect of Perl 6?
Are you aware that it's possible to use ordinary Perl 6 code with modules from Python, Ruby, Lua, Perl 5, etc.?[4]
I'm no Perl user, but surely 800 is pretty good for a one year old language? How many did Perl 5 have when it was one year old? (That's a trick question: CPAN was officially launched about year after Perl 5 came out; see here http://history.perl.org/PerlTimeline.html)
PAUSE is ugly, though I mostly use automated uploaders so I don't have to look at it.
I'm not sure what you find archaic about CPAN, the package/distribution distinction is a huge win that the rest of the world still hasn't caught on to, and the file-based nature means it scales stupidly well (npm's scaling issues simply can't happen to us).
Unless by archaic you mean "built as simply as possible, and built to last", which is basically why I love it :)
You can request pre-warming for additional ELB capacity, when you know far enough in advance that you will have a spike. AWS customer service responds by asking 10 clarifying questions via email. The thing is, we can't look under the hood to see currently provisioned and utilized ELB capacity, so we just have to trust that AWS engineers will properly allocate resources according to the answers to those questions. IMO, it's a rather cumbersome process that would be better implemented as a form.
It is weird that given how much in the way of tools and self-help that AWS gives you, that prewarming involves this manual process involving a dozen questions, some of which are unanswerable, and there's no 'pre-warming' form to fill out - the service rep gives them to you in free text.
It's not clear why it's not useful? The OP said hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc., so wouldn't he just tell Amazon "Hey, we get xx requests/second at our peak, so we'd like the ELB ready scaled to handle that load"?
If you install this Chrome extension, it has the ability to "read and change your data on all google.com sites." Why is this necessary? Seems like quite an overreach.
This permission is required in order to capture text from mail form. Gmail operates under mail.google.com domain. You can examine the extension source code to see that it is not doing anything other than this. It encryptes the content in your browser and sends the encyrpted data to Snapmail servers to get the link.
I know that there are lots of heavyweight folks who swear by Zookeeper as both a reliable and powerful tool, and for good reason. Unfortunately the docs can be fairly inscrutable, even for experts, and it typically requires the maintenance of a separate cluster of Zookeeper nodes.
So I like that etcd is a fundamental component of CoreOS, with these features:
1. Written from scratch in Go
2. Implements the Raft protocol for node coordination
3. Has a useful command line app
4. Runs on every node in a cluster
5. Enables auto-discovery
6. Allows CoreOS nodes to share state
No offense, I just don't get it: Why is 1) a feature for you? Everything else on the list kinda makes sense (I understand that this describes something I'd call a feature), but 'written from scratch' or 'in Go'?
I guess what I meant by "from scratch" is that they aren't burdened by legacy code, and aren't limited to using the Paxos algorithm.
If you look at Deis, for example, it basically outsources a lot of node management to Chef Server, which in my view creates a great deal of technical debt on day one.
You read negative connotations into 'excites'. That wasn't intended.
I was just curious, since 'from scratch' can just as well mean 'untested' although I certainly agree that it sometimes is the Right Thing. The reference to Go was another thing that threw me off, since I rarely (admittedly .. sometimes) judge software projects by the language it is written in.
Thank you for the answer and some more references.
Probably the fact that you get a single binary (unlike interpreted languages), and that it isn't a mix of Go and C meaning I worries about c libraries.
Personally, my preference for zookeeper comes from the API. To me, the ZK API and docs were far more understandable than the etcd ones. The etcd api docs appear to be a collection of examples, not reference docs. It does a poor job of explaining the possible operations and what various options will do, particularly in what combinations of options are allowed.
In fact, I had to resort to running test queries against a running etcd server just to work out the proper semantics of some of the arguments.
The functionality to handle this is mentioned in the blog post: "standby" peer mode.
"Our upcoming release, etcd 0.4, adds a new feature, standby mode. It is an important first step in allowing etcd clusters to grow beyond just the peers that participate in consensus."
Fair enough, it just sounded like the GP was describing something inherent rather than something new, and it didn't mesh with my understanding of how etcd worked to date.
As you (perhaps automatically) expand and collapse the cluster, you'll need to make sure to communicate to all nodes what the new cluster size is. If some nodes don't know the correct quorum count, split-brain!
Also, coordination services are typically critical, so its important to isolate from to the bugs in the adhoc code you're writing for your web tier, a crazy query in your database, etc.
It's much easier and safer in practice to just have 3 or 5 nodes running the coordination in isolation.
Edit: more reasons -- It's easier to deploy a coordination service to 5 nodes than 500. It's easier to debug 5 nodes than 500.
I probably should have said that it "can" run on any node. Yes, currently it does run on every node, but their roadmap doesn't have the requirement that every node be actively participating in elections.
I'm sure that you have seen fleets of dedicated Zookeeper nodes. I rather like that etcd is simply a service that can run on any node, and does not require a separate role-specific fleet of servers just to do coordination. That was the point I was attempting to make.
Furthermore, we are left to wonder if Microsoft is also being fed “bullshit” patches, and if they may be less discerning than Linus regarding a proper solution.