261–270 of 567 posts
Will there be any way to disable or block the upcoming patches and keep the performance for those of us who really just don't have any reason to care about inter-process information leakage on our personal computers? Edit: I'm (also) wondering about Windows, in case anyone knows yet.
Earlier quoted context omitted.
As i understand the problem, this isn't about clockspeed reduction, now it is the software's responsibility to check if the page is a kernel page/user page. So, the impact is significant. So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower.
Right, but how often that happens is workload dependent. Basically, how often is your code making syscalls.
Or am I completely off the mark?
Earlier quoted context omitted.
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.
Don't flash devices use nvme (eg userspace queues) now and avoid the kernel all together for read and write operations? Shouldn't they have no impact?
Earlier quoted context omitted.
If you overflow that buffer, you can overwrite the return address in the kernel stack, which you can then launch into ROP. The crucial point here being that there must already be an existing overflow vulnerability in the kernel. Knowing all the addresses is no use if you can't force execution to go to them.
The hypothesis I've seen, and why people seem to be rushing to patch it without explaining, is that you might be able to not only leak addresses, but actual data, from any ring, into unprivileged code, at which point, your security model is burned to the ground. AIUI, the present circumstances are: - there exists a public PoC from some researchers of side-channel leaking kernel address information into userland via J…
Earlier quoted context omitted.
Do we have a performance estimate? I can eat 20 or 30%, but I can't eat 90%.
This comment further down thread mentions it's 20% in Postgres. https://news.ycombinator.com/item?id=16061926
The reply to that comment is accurate: that's a pathological case. Probably an order of magnitude off.
Earlier quoted context omitted.
How you hold this stock is a mystery to me. With it bouncing between $10 and $15 constantly last year it just seems far to volatile. I'd be panic buying / selling every day to adjust which seems stressful... Maybe why its a favorite of /r/wallstreetbets
You're doing it wrong if you're day trading stocks... dollar cost averaging is your friend when it comes to volatility and well if you're investing you're doing so because of long term belief in the company so it should be easy to hold and not worry about it.
Research suggests otherwise:
https://personal.vanguard.com/pdf/ISGDCA.pdf
Diversification is a more effective strategy for dealing with volatility.
Here are some numbers quantifying the problem. Big caveats apply as they are very preliminary, but the hit due to the software patches looks extremely significant: https://www.phoronix.com/scan.php?page=article&item=linux-41...
Phoronix strikes again! I admire Michael's consistency and dedication and their benchmarks have certainly gotten better over the years as PTS has matured, but everything on Phoronix still needs to be taken with a generous helping of salt. New readers generally learn this after a few months; it applies not only to their benchmarks, but also their "news". The most obvious issue with this benchmark is that Phoronix is t…
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
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…
Add on top of that the fact that a lot cloud customers over provision (there's good scientific papers on how much spare CPU capacity there is). Cloud service providers that sell things on a per request / real CPU usage model (vs reserved capacity) prob benefit more.
Also, you can't just separate trading in AWS or GCE from the rest of the core business.
Potentially business units of DELL, HP, IBM, ... should do better as people use this as a justification to upgrade overdue hardware they should cover 5% to 10% lower performance (needing more units to cover that).
This is a clusterf /big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming…
It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Intel Kernel Page Problem building.