21–30 of 262 posts
Another nail in the casket lake. Is the solution just to throw everything out and start again? Do we just abandon speculative execution?
Spectre variant 1 is probably unavoidable so security inside a single virtual address space is kinda dead. Use separate processes and mmu.
One question- do these vulnerabilities , including spectre and meltdown only help in stealing information or can they also hijack your computer to do arbitrary things?
If you steal passwords, then you can use said password to hijack whatever the passwords are protecting.
If you steal private keys, you may be able to use said keys to impersonate the victim (like via ssh into their remote machines).
But if you're asking if speculative vulns could directly lead to remote code execution, then no (since you already have given the attacker a measure of control, as they are able to execute code already).
Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels. - name: Disable CPU-sapping security mitigations become: yes lineinfile: path: /etc/default/grub line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off…
AMD is suffering much less from these flaws. Seems they didn't ignore as many security boundaries with their implementation.
AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
> AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
Putting memory permissions check in retirement stage of the pipeline couldn't be accidental, I say...
Sounds like a great "efficiency hack". Till it fucks up.
Earlier quoted context omitted.
> This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it. Interestingly, that printer monopoly seems to be doing fine today, given how I have to go to hp.com to get drivers for my Samsung printer.
HP used to be much more. It was a real innovative company. But the interesting parts have been spun out like: Agillent and Keysight. HP Enterprise was also spun out.
One question- do these vulnerabilities , including spectre and meltdown only help in stealing information or can they also hijack your computer to do arbitrary things?
It doesn't immediately give code exec, but generally it wouldn't be very hard to turn arbitrary memory read capabilities into privilege escalation. As long as you know what the system is running.
Is it possible to apply the mitigations on an per-application level in Windows? IMHO it'd be pretty useful to be able have them on by default, but disable them for specific applications where you care about maximum performance and know that you won't be running untrusted code.
Is the answer (for home users) to just sandbox some processes under an emulator layer? I'd be happy to just sandbox some sensitive processes like my browser even if it took a huge performance hit, so long as some other apps like games did not take the same hit.
Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels. - name: Disable CPU-sapping security mitigations become: yes lineinfile: path: /etc/default/grub line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off…
Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.
It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't be running JS anyway.
AMD is suffering much less from these flaws. Seems they didn't ignore as many security boundaries with their implementation.
AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.
One question- do these vulnerabilities , including spectre and meltdown only help in stealing information or can they also hijack your computer to do arbitrary things?
It can be used to defeat ASLR, which is a way to make exploiting code harder. However, defeating ASLR just makes it easier to deploy an exploit against a program, but you still need the exploit. It doesn't immediately give code exec, but generally it wouldn't be very hard to turn arbitrary memory read capabilities into privilege escalation. As long as you know what the system is running.