Probably not. APFS just does a lot more then HFS, so there is a huge performance impact on disk related issues before this change goes in. This is a all hands on deck kind of situation. Apple doesn't usually do well with security firedrills like this.
If work in NT and Linux kernels started on November, they must know. Intel must've told them, the alternative of Apple learning about this from a third party and grilling them over it would be too scary.
I just wonder whether Apple is threatening to move all their Macs to AMD, or to ARM?
If they really care about peak performance, I don't believe the PTI patch will affect them. If you can change your system in a way that the power-hungry part does not work on untrusted data, you can not with "nopti" and ignore it. Systems which both need lots of maxed-out CPUs and traffic directly from wild internet are pretty rare. They're unlikely to run on a virtualised systems either.
Systems which both need lots of maxed-out CPUs and traffic directly from wild internet are pretty rare. That's a good description of basically every cloud environment out there, from AWS on down. In other words they are extremely common.
There are many ways to tune such workloads and I suspect our software will get better as a result.
We'll start to get conscious about the number of syscalls we use on each operation, start using large buffers, start buffering stuff user-side...
Problem is, most companies that need a lot of power only care about one thing - peak performance. And they tune it carefully in order to not overspend while guaranteeing minimal downtime. This means that they'll have to pretty much scale their infrastructure up by exactly 30%. That's a LOT for these big clients. Honestly, I'd just make sure the server firewalls are super tight and not take in the future patches. At l…
Very very few highly tuned "peak performance" workloads are dominated by syscall overhead like the test that produced that 30% number was. It's best to hold off on the hyperbole.
No, but lots of workloads are built with latency in mind. For APIs that talk to each other in long serial chains, don't be surprised if request responses take significantly longer in many, many workflows.
What started as speculation about recent kernel developments has really turned into a shitshow for Intel. I can't imagine they thought that these massive changes would get through without anyone finding out. However, there really isn't any other better option for Intel, so it seems they are in a lose lose situation with no way out. Or at least a way out that doesn't involve them going bankrupt trying to repair the da…
> going bankrupt trying to repair the damage. I think you took it a bit too far. May be, I am missing something. Is it really that bad?
There are at least tens of thousands, possibly hundreds of thousands of Intel CPUs in just datacenters around the globe. Most of which are controlled by companies that make a lot of money and paid a lot of money to intel for their CPUs. And I doubt that they will just take this kind of hit to their performance sitting down. And thats just datacenters, not to mention all the personal computers (mine included) that will suffer. At this point, if this is real, its not a question of if it will cost them, its how much. And considering the sheer numbers of the products affected, I can't imagine it will be cheap. I am not saying that I think they are going to go bankrupt, and I would be surprised if they did, but a 30% percent performance hit is multiple generations of fallback, and considering the importance of computing today (and the number of different entities that are affected by this) I find it hard to imagine that it will be just taken sitting down.
Thanks for summarizing. Does anyone have time to link to more on the "side-channel leaking kernel address information into userland via JavaScript" ?
This isn't exactly that, but here[1] is a talk linked in the post from the other day which shows a PoC breaking ASLR in Linux from JavaScript running in the browser, via a timing attack on the MMU. There's a demo a half hour in. EDIT: This post[2] discusses the specific speculative execution cache attack and claims there is a JavaScript PoC (but doesn't cite a source for that claim) [1] https://www.youtube.com/watch?…
As I mentioned in the other thread yesterday database and database like applications are going to be hit particular hard. Even more so on fast flash storage. Double whammy compared to apps just doing network IO. And while databases try to minimize the number of syscalls they still end up doing a lot of them for read, writeout, flush.
How would you trade this knowledge? Intel has already dropped and AMD is up. Maybe there's more to move, but first-order effects are at least partially priced in already. But what about second-order effects? Seems like virtualization should be vulnerable (VMWare and Citrix), but maybe they actually benefit as customers add more capacity. Software-defined networking and cloud databases should also suffer though it's u…
Automated ic-layout and software proofing benefits from this.
You can be sure there's a young hotshot with sparkling eyes at SEC who is already typing a letter to Mr. Krzanich politely asking about the circumstances of that sell. At the same time, noone is doing eight figures transactions which require reporting to the SEC without talking to a lawyer. Right? Right? They really dislike insider trading, it's one of the few things where even rich people can get imprisoned -- and t…
> They really dislike insider trading, it's one of the few things where even rich people can get imprisoned -- and the typical jail sentence has been steadily climbing up for decades now. Insider trading, like many white-collar crimes, exists primarily for its value as a weapon. There is nothing actually illegal about the act of selling a stock; it's all about casting aspirations as to intent and who-knew-what-when.…
The expression you're looking for is "casting aspersions."
This reminds me of a storyline from The West Wing, where a company that was Intel in everything but the name found a bug in their chip.
As it threatened the company's existence, the President refused to consider guaranteeing a loan because the company had been a contributor, and any help could potentially appear as corruption.