211–220 of 232 posts
"One almost wishes that they’d stuck with the original name for the KPTI patchset: Forcefully Unmap Complete Kernel With Interrupt Trampolines.
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl... "
Now that's funny!!!
Earlier quoted context omitted.
I doubt that any CPU manufacturer is going to go first in crippling its memory subsystem. I think realistically the only safe and not completely performance crippling workaround will be, at the very least, to run any untrusted code under a separate address space (assuming that the cpu is immune from meltdown). That doesn't necessarily require a full blown separate process, but something like memory protection keys mi…
Yeah, i don't disagree at all. Something like this what i meant by "cooperation" (lfence or equivalent for code that can't be isolated but must be protected) + "weird abstractions" (IE back to segmented land we go)
Earlier quoted context omitted.
If I understand it correctly, Spectre only works within a single address space.
Well... I never expected one part of my process not to be able to peek into what the others are doing.
Earlier quoted context omitted.
> can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? From what I understand, it does happen on AMD, which is why AMD CPUs are not vulnerable to the more dangerous Meltdown attack (any code reading kernel / hypervisor host memory). Intel / ARM delays the checks until later, to the time when the speculated instructions are actually finalised an…
> This means that all sorts of sandboxing methods for javascript interpreters, bytecode interpreters, plugin architectures, etc are insecure. I just now understood the impact of Spectre. It is not just that all existing attempts to execute code in a sandbox are vulnerable. For CPUs with this problem, it is literally impossible to create a secure sandbox. We certainly live in interesting times...
(hoping for someone to correct me if I'm wrong)
Earlier quoted context omitted.
Branch prediction is neither new nor modern. Modern state of the art design doesn't actually do branch prediction in hardware at all. I mean look at all the ideas from VLIW architecture, no hardware - no problems.
You're being pretty silly by zeroing in on the word modern and then using an equally silly redefinition of it yourself. Branch prediction isn't new, you're right. But VLIW instructions are equally unmodern and are entirely orthogonal to speculative execution. Sufficiently smart compilers are also no substitute for runtime analysis.
Earlier quoted context omitted.
Well... I never expected one part of my process not to be able to peek into what the others are doing.
One example would be malicious Javascript - or WebAssembly - strolling through your browser's memory looking for passwords to send home to the mothership. Or other sensitive information, like credit card numbers and so forth.
What would finally bring this all together to me would be an example of a real world attack that would be carried out using these methods on some target, perhaps with an implementation.
And I'll offer that if you're not capable of demonstrating it after reading Eben's description of how it works than there is no good reason for you to have an example handed to you.
If you think you are capable I'll offer your time would be better spent working on fixes.
Earlier quoted context omitted.
You shouldn't be comparing plain text passwords anyway. You should be using a secure password hash, such as bcrypt, sure, you should use constant time comparison, but in this specific case, it won't really make you vulnerable to use normal comparison.
Normal comparison is bad even if you are comparing hashes. Letting the attacker figure out the password hash allows them to attempt to crack the password through an offline brute-force attack running on GPUs.
> User enters password > PW gets hashed > Hash gets compared to the DB
I don't know of any same system that would allow you to compare a hash to a hash? Unless you have access to something you shouldn't, in which case it doesn't matter anyway, because you can probably just read the hashes.