161–170 of 567 posts
If I understand well, there may be a serious bug in some x86 CPUs but nothing is known publicly. Presumably, all current Intel CPUs are affected and none by AMD but we can't really be sure, it is still a secret.
It is impressive how a simple, yet to be justified patch has so much influence. It opens up new ways of manipulating the market...
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…
Well, if I rent a VPS with x performance, I still expect x performance after this flaw is patched. The company providing the virtual machine will perhaps have to pay 30% more to provide me with the same product I've been getting.
Since most VPS offerings arbitrage shared resources, this will not increase costs of providing VPSes by the full performance penalty.
Earlier quoted context omitted.
This is typically what happens when you go for a long time without real competition. You get way too comfortable and bad habits start to pile up.
Isn't why this problem even exits the exact opposite? Intel was losing on the mobile market and changed internal testing to iterate faster by cutting corners. Found a quote: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our comp…
As other comments suggest, there might be a third stage, completely forgetting how to design and validate chips properly.
Perhaps a bit off topic but I have an (Asus) laptop with a recent Intel chip running Linux (Solus) and I have no idea how I am to deal with all these CPU bugs... Any pointers?
Earlier quoted context omitted.
I have no idea how or if this is a big deal but: >>attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. if you're going to put in features with expected attacks you should definitely be putting in features to prevent it , and if it is an expected attack it shouldn't be special measures it should just be an inherent part in introducing the fea…
When speculative execution (and caches) were invented and put into widespread use, no one thought about timing attacks, nor was the practice of running untrusted code on one's own machine common.
Doesn't multi-user timesharing and virtualization predate every modern CPU and OS though?
Perhaps a bit off topic but I have an (Asus) laptop with a recent Intel chip running Linux (Solus) and I have no idea how I am to deal with all these CPU bugs... Any pointers?
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…
> claiming for a class lawsuit against Intel If people who received written assurance from Intel that their hardware is 100% bug free can form a legal class, sure. I highly doubt there is even a single one such customer.
Earlier quoted context omitted.
Reading secret data out of kernel memory is very bad on cloud environments. Keep in mind that the kernel deals with a lot of cryptography.
Is there anything this bug can give you that you can't get with sudo cat /dev/mem ? I'm having a hard time understanding why this is worse than any other local root escalation bug except for the consequences of the necessary patch. EDIT: I see that /dev/mem is no longer a window on all of physical RAM in a default secure configuration. Is it true that there's no way for root to read kernel memory in a typical Linux i…
Earlier quoted context omitted.
So this is evil for virtualization hosting, which is the major enterprise application for Intel chips. Hosting on bare metal will become more attractive. Too bad you can't long OVH and Hetzner.
>Too bad you can't long OVH and Hetzner. What does that even mean? Also Hetzner just introduced some AMD Epyc server.
As opposed to "shorting" a stock, which means making a bet that it will go down in value.