251–260 of 337 posts
Earlier quoted context omitted.
Can we actually compute without branching? Genuine question. What architecture would do that, and how?
You can compute with less than that. (all links are to the same thing) https://github.com/xoreaxeaxeax/movfuscator https://m.youtube.com/watch?v=R7EEoWg6Ekk https://news.ycombinator.com/item?id=18991404
Earlier quoted context omitted.
The stream of critical CPU vulnerabilities starting with Spectre/Meltdown last year are related to speculative execution , not just Intel. (AMD and ARM CPUs are also vulnerable to Spectre, for example.) Intel CPUs are sometimes vulnerable to additional attacks because they speculate in more scenarios than other designs. But fundamentally, as long as multiple different trust domains are sharing one CPU that speculates…
We were talking about alternative CPU designs and a guy commented on how much of the volume of a CPU is memory these days. I wondered aloud if it wouldn’t be better for use to embrace NUMA, make the bigger caches directly addressable as working memory instead of using them as cache.
What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…
The easiest prevention is to stop running untrusted code, or don't start doing so if you're not already. The "elephant in the room" with all these attacks starting from Spectre/Meltdown is that an attacker has to run code on your machine to be able to exploit them at all. To the average user, the biggest risk of all these side-channels is JS running in the browser, and that is quite effectively prevented by careful w…
Earlier quoted context omitted.
> Why don't we have a CPU architecture where a master core is dedicated to running the kernel and a bunch of other cores run userland programs? How will your "userland core" switch to other userland programs safely? A pointer-dereference can be a MMap'd file, so its actually I/O. This will cause the userland program to enter kernel-mode to interact with the hardware (yes, on code as simple as blah = (this->next)... t…
Sounds like we would need a new paradigm for how to handle that. But it seems to me that x86 is in now way the panacea of COU design. Wouldn’t you gain some good trade offs by changing up how things are done?
In-demand paging is another situation where a simple pointer-dereference can suddenly turn into a filesystem (and therefore: kernel-level / hardware-level) call.
Earlier quoted context omitted.
The easiest prevention is to stop running untrusted code, or don't start doing so if you're not already. The "elephant in the room" with all these attacks starting from Spectre/Meltdown is that an attacker has to run code on your machine to be able to exploit them at all. To the average user, the biggest risk of all these side-channels is JS running in the browser, and that is quite effectively prevented by careful w…
I think that's a cop out. A system should be secure enough to isolate untrusted code.
Earlier quoted context omitted.
>hardline views on security The only hardline view on security you'll encounter in the wild is "security is practical in our computational environments"[1]. Only half-joking here. My reading of Theo's quote is merely "the combination of x86/IA32/AMD64 and virtualization gives little to no factual security benefits, and plenty of pitfals". I don't see Theo as being a hardliner about security, just meticulous about goo…
Except that's objectively wrong - x86 virtualization breakouts have been extremely rare in practice, and fixable till recently. The new class of attacks we now see target any type of shared code execution environment. OpenBSD is as vulnerable to this as anything else.
What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…
> What is the recommended course of action? Stop buying Intel products, and devices which contain them? There is absolutely nothing to be done on our level about this. I'm fairly convinced this is systemic issue that can only be solved by redesigning almost entirely modern cpus and computers architecture. I can draw a parallel to approximately all Intel cpus which are know to have a dedicated "mini cpu" called "Minix…
What exactly is "our level"?
Earlier quoted context omitted.
We were talking about alternative CPU designs and a guy commented on how much of the volume of a CPU is memory these days. I wondered aloud if it wouldn’t be better for use to embrace NUMA, make the bigger caches directly addressable as working memory instead of using them as cache.
I’ve heard somewhere that some or all versions of intel atom are immune to both spectre and meltdown attacks. The bonnell architecture being just a supercharged 486 has none of those fancy features that are being exploited. Not sure about foreshadow since HT is present on Atom processors.
Per Wikpedia, "The Pentium has two datapaths (pipelines) that allow it to complete two instructions per clock cycle in many cases. The main pipe (U) can handle any instruction, while the other (V) can handle the most common simple instructions." (https://en.wikipedia.org/wiki/P5_(microarchitecture) )
HT uses two instruction decoders to keep more busy a set of execution engines, suppose you had the above set of 2 execution datapaths (that may be improved on these Atoms), and couldn't do two operations at a time from one instruction stream, but the other could use the unused datapath.
Earlier quoted context omitted.
Security by obscurity is no security
This saying rubs me the wrong way, because confidentiality is 1/3 of security. Obscurity is critical or this wouldn't be a vulnerability.
"Obscurity" general refers to situations where "everything" is confidential. And when everything is confidential priority one, nothing is, since people can't work like that.
Cryptography attempts to sequester the confidential data into a small number of bytes that can be protected, leaving larger body of data (say, the algorithm) non-confidential.
Earlier quoted context omitted.
The easiest prevention is to stop running untrusted code, or don't start doing so if you're not already. The "elephant in the room" with all these attacks starting from Spectre/Meltdown is that an attacker has to run code on your machine to be able to exploit them at all. To the average user, the biggest risk of all these side-channels is JS running in the browser, and that is quite effectively prevented by careful w…
I think that's a cop out. A system should be secure enough to isolate untrusted code.
All depends on your threat model; to take one extreme, if you're crunching numbers with your own optimized numeric code, the issue of untrusted code of "random JavaScript off the net" is not an issue. And I doubt many mainframes are used to casually browse the net ... I certainly hope not at the same time they run the night's financial transactions!