Originally posted by kruger
View Post
Announcement
Collapse
No announcement yet.
A Look At The CPU Security Mitigation Costs Three Years After Spectre/Meltdown
Collapse
X
-
Originally posted by Mangix View PostWhy is that?
Comment
-
Originally posted by Mangix View Post
Why is that?
The average customer that is using x86 typically don't care that much about security and are happy with the mitigations that are in place. I don't agree, but it is what it is. Intel's goal is probably just to match AMD's security which it seems like they have accomplished now. They will likely prioritize performance improvements since there's a higher demand for it.
It looks like the Raspberry Pi 4 was vulnerable to SSB until 5 months ago and nobody noticed (or reported) it prior to that. The hardware is still vulnerable but at least the mitigations are applied in the latest updates. There are still some minor kernel problems that needs to be solved in the official Pi kernel (based on 5.4, upstream mainline does not have this problem). I have some concerns about it since I'm running k8s on a Pi4 cluster. It's a hobby project I have limited time to investigate and test. Anyway these problems are expected when you have a small budget and maintain your own kernel and firmware. I don't blame the engineers, they seem to be doing a good job.
The PR team and forum feedback leaves much to be desired.
1) https://www.raspberrypi.org/blog/why...e-or-meltdown/
2) https://www.raspberrypi.org/forums/v...c.php?t=243416
Comment
-
Originally posted by carewolf View Post
The JS engines are also isolating, and have been compiled to do that on their own.
- Likes 1
Comment
-
Originally posted by Jabberwocky View Post
No. This is not wise. Don't recommend this to others.
your software (this is possible, even with the web), evaluating risk, and needing all the speed of your machine.
Given a (reasonably) safe environment is met, it is a bit wasteful to not use the full speed of your CPU
for vulnerabilities that have probably waaay less chance to be exploited that to win at the Euromillion lottery.
Again, people have different priorities. I need my Linux work PC to be fast and only install packages from my distro whose packagers I trust.
- Likes 1
Comment
-
It's worth remembering that the mitigations' penalties are not only in terms of CPU performance but also, with some hardware, really serious stability problems. I run old stuff, Core-i5 on Sandy Bridge (LGA 1155). With latest Intel microcode loaded and enabled I found my PCs (different ones running Debian Testing and Windows 10) to be a real nightmare. There were sudden shutdowns, failures to resume from S3 sleep, failure to hibernate, failure to boot reliably, system freezes, higher temps, more fan noise and so on. I disabled the mitigations and my machines returned to their original, rock solid, boring, very quiet, reliable selves. Everything works perfectly again. On the Windows 10 PC 3D gaming on Steam returned to being smooth & reliable instead of jerky and liable to crash without warning. I've also disabled mitigations on my Intel Atom devices. One I use running Win 10 as a TV box (because Netflix annoyingly only allows 720p on Linux but 1080p is fine on Win on the same hardware!) and it was hopeless until I used the inspectre tool from grc.com to disable mitigations. Another Atom device runs a tvheadend server, DVB-T2 tv stick using Debian and yes, I disabled mitigations on that too and it's great.
If anyone can point to definite, verifiable & successful real world attacks on unmitigated x86 PCs I'd be very interested, genuinely, as if it looks serious I have to start saving up many thousands of pounds for much newer hardware. Meanwhile I'm happy with my 2013 powerhouses
- Likes 1
Comment
-
Originally posted by bobbie424242 View Post
I don't particularly recommend it, unless you know what you are doing, which includes trusting
your software (this is possible, even with the web), evaluating risk, and needing all the speed of your machine.
There are many people with decades of programming experience and top positions at companies who don't fully understand these attacks. I have spoken to people with B.Sc. (Hons.) in CS that still do not understand the attacks despite their credentials. On the other side people with no formal education or at least not CS related and are providing workarounds to the problems or writing pen-tests. The point is: This problem requires years of specialization to understand how this impacts your systems.
In most cases obtaining this specialization is not productive and does not help your business or career so there's little incentive for someone to obtain it. There still are people that are passionate about these problems and enjoy it as a hobby who don't need a financial incentive, yet IMO it's a dying breed. From a philosophical perspective it's not very practical either as a hobby.
Given a (reasonably) safe environment is met, it is a bit wasteful to not use the full speed of your CPU
The best way IMO to prevent side-channel attacks on faulty hardware without software mitigations is to run trusted software[1] and to prevent or sandbox[2] remote code or even remote data. Meaning don't connect your computer to the internet or if you do make sure there are no vulnerabilities in software that send or receive network requests. In the past if you ran apache via the "www-data" user if someone found an apache exploit then they were limited to that user. That is no longer the case if the attacker is using side-channel attacks. The attacker cannot automatically read your entire FS or simply just copy your SSH keys, they need to wait for you or one of your services to access it before they can read it. This gives attackers much more vectors to infiltrate sensitive parts of a system. This is why side-channel attacks are such a big problem for cloud providers, attackers can skip the first exploit completely. You already have the ability to run code when they sign up and start a non-dedicated instance.
1. How does packages become trusted? Is it because there are no reports of problems, do you trust the individuals who evaluate the packages, or those that originally write the software of those packages?
2. Sandboxes are not impervious to attacks.
for vulnerabilities that have probably waaay less chance to be exploited that to win at the Euromillion lottery.
Again, people have different priorities. I need my Linux work PC to be fast and only install packages from my distro whose packagers I trust.
If someone doesn't care about leaking their information nor do they have information about other people or businesses, by all means turn off the mitigations.
If someone has other people's data or code on their machine, it's better to err on the side of caution. They just might win the lottery on the same day as a few others without knowing.
Sorry for the long reply. I think it's important to understand first and then to choose priorities. I hope it helped in some way.
PS: In theory security to me is about not taking chances. I know it's not always practical. Yet odd things happen... Last month my country's (South African) lottery ended with numbers: 5, 6, 7, 8, 9, and 10. The exact order was 8, 5, 9, 7, 6 and extra powerball 10, still people here lost their minds
- Likes 1
Comment
Comment