the fact that intel can't even fix these vulnerabilities ( amd and zen 2 seem to be doing better ) after the fact just makes me more confused over how even high performance ( with branch prediction ) risc v cores are immune to them
Announcement
Collapse
No announcement yet.
Intel Prepares "Enhanced IBRS" As Better Spectre V2 Protection For Future CPUs
Collapse
X
-
Originally posted by GunpowaderGuy View Postthe fact that intel can't even fix these vulnerabilities ( amd and zen 2 seem to be doing better ) after the fact just makes me more confused over how even high performance ( with branch prediction ) risc v cores are immune to them
Same as AMD x86 CPUs aren't similar to Intel and aren't 100% affected by everything that affects Intel processors.
This means that RISC-V per-se isn't immune, but current RISC-V designs are immune due to their actual hardware design. There can be RISC-V designs that are vulnerable, as it depends from the hardware design itself.
Intel can't fix this easily as they need to change something fundamental in their architecture and that requires time and skill to pull off right. Assuming they want to, as I'm sure they can't provide safety without sacrificing performance, so I think they are settling on a "let the consumer choose" kind of deal where they have mitigations that can be disabled if you don't need security.
- Likes 1
Comment
-
Originally posted by Mthw View Post
Is there really?
Comment
-
Originally posted by starshipeleven View PostRISC-V is an ISA, RISC-V actual hardware will differ from each other.
Same as AMD x86 CPUs aren't similar to Intel and aren't 100% affected by everything that affects Intel processors.
This means that RISC-V per-se isn't immune, but current RISC-V designs are immune due to their actual hardware design. There can be RISC-V designs that are vulnerable, as it depends from the hardware design itself.
Intel can't fix this easily as they need to change something fundamental in their architecture and that requires time and skill to pull off right. Assuming they want to, as I'm sure they can't provide safety without sacrificing performance, so I think they are settling on a "let the consumer choose" kind of deal where they have mitigations that can be disabled if you don't need security.
I just don't get it why not just make rdtsc with a lot of jitter and other hardware timers and solve it forever.
Obviously this should be a thing able to be controlled by the kernel, so that apps that rely on precise timing measurements can be given the privilege of "exact" timing results instead of having it with random jitter.
tl;dr; reduce precision of the timers to micro-second levels by default, and you solve the problem. Make it so that the kernel can control this per process and can give a process exact precision if needed (needless to say you should only use that on processes you trust!)
Comment
-
Originally posted by Weasel View PostI'm wondering why can't they just make rdtsc or other high-performance counters very imprecise (at the micro-second level and above) so that such attacks are completely eliminiated?
Obviously this should be a thing able to be controlled by the kernel, so that apps that rely on precise timing measurements can be given the privilege of "exact" timing results instead of having it with random jitter.
Lol and all the applications that will require this even without any logical reason to... oooh it will be awesome.Last edited by starshipeleven; 25 July 2018, 08:34 AM.
- Likes 1
Comment
-
Originally posted by starshipeleven View PostBecause that's the whole point of high-performance counter to be precise.
Originally posted by starshipeleven View PostWho knows what applications need it? I)'m ready to bet that it would cause a ton of breakage until people figure out this.
Even if an app relies on timers, it doesn't mean it relies on precision in them, necessarily. The amount of breakage would be pretty low, IMO (except for critical apps but you already give those full access anyway, since they're "critical").
Or just set it only for untrusted apps (like those with internet access), others can't really spy on you if they're offline anyway. A lot of possibilities.
- Likes 1
Comment
-
Originally posted by Weasel View PostYeah, and the whole point of root is to have access to everything on your machine (usually). It doesn't mean it's a good idea to give it to every application.
You can always just set the capability by default to every application if you don't want to bother with selective whitelisting, you won't be less secure than right now. But proper security practice is to deny by default and only selectively allow, obviously it doesn't mean everyone follows it, nor is it required with my idea.
Even if an app relies on timers, it doesn't mean it relies on precision in them, necessarily.
Or just set it only for untrusted apps (like those with internet access), others can't really spy on you if they're offline anyway. A lot of possibilities.
Your thinking works only in modern OSes like Android where apps that don't need internet access actually don't have that permission, so even if compromised will NOT be able to access the internet anyway.
Comment
Comment