I need to take a look at the patches (on mobile now), but can anyone comment on how a barrier at unlock can provide ordering between mmio accesses under the same lock? Or is it required that every register have a unique lock?
1,988 karma · joined January 22, 2018
the primary reason is that it is not remotely comparable to the theft of trade secrets in my example. If the gardener put their garden in a greenhouse and put a padlock on the door, then the scenario would be more comparable, but then it wouldn't make a lot of sense to say it should "obviously" be legal for someone to break in and take a sniff, because it's just a sniff, right?
Your parent/child analogy is poor because you are just describing an investment that doesn't pay off for any number of reasons, not that somebody stole the value from you. Perhaps more comparable would be if a parent raised a child until adulthood, at which point someone stole the young adult, brainwashed them to think they were the parents, and the child visited the fake parents in their old age.
That sounds far fetched, but it is far more comparable to the scenario I introduced of someone stealing a company's intellectual property and profiting off of it.
Apple (the original creator of opencl) has deprecated it on their platforms in favor of metal.
I think Intel has implementations, but IMO you are better off with ISPC if you are targeting a CPU.
I have a hard time keeping up with AMD's overall direction, but the latest ROCm stuff seems to focus on an implementation of CUDA AFAICT.
Nvidia apparently has no intention of focusing on opencl.
Support for opencl 2.0+ is poor. Some vendors have support, but most are partial or language only (mostly meaning c++ for compute shaders, but not the other features). IIRC, even AMDs ROCm opencl is not 2.0.
And then there are all the fpga/accelerator vendors. I don't have much experience with opencl on these, but I expect they will also move away from opencl - I'm interested to see what Xilinx does with Everest, since it will supposedly be easier to develop for than traditional FPGAs.
Vulkan compute or implementations of cuda from other vendors seem much more promising. OpenCL tried for a "one standard fits all compute," but I don't think it has worked out that well. It leads to a "write once for all platforms, optimize separately for each platform" at which point it's better to just have different standards specialized for the target. For a long time code written for one compiler wouldn't even compile with an implementation from another vendor.
Let's say a U.S. company spends a billion dollars creating a chip design. You think that it should not be illegal for other companies to steal said chip design and manufacture it because it is just "copying data?" So the company that invested to design has to compete with a company that stole it, and therefore can price it lower because they don't have to recoup that investment?
Just because something can be copied more easily now than when it required a bunch of photocopying doesn't mean it isn't (or shouldn't be) a crime.
I would argue that it is different, because it has computers in it.
> The biggest digital systems we have now have been consciously and deliberately designed to monitor and manipulate human behaviour.
They've been designed to make users click on this or that or watch or scroll more, but I disagree that all the consequences of those designs were or are understood. I don't think anyone intentionally designed a system to make kids watch creepy YouTube videos endlessly or not get vaccinated or think the earth is flat, they designed a system to "maximize engagement" and these things happened (maybe or not as a consequence).
I don't think his point is about whether the integrator and analog electronics will be resurgent in the next century, and analog hardware will be common.
I think Dyson is talking about the complex network of the modern world, where humans interact with computing machine, and with each other - humans influence computers, and computers come back around and influence humans. I think his "future of computing" is a future where human society and culture is decided based on the interplay between humans and our machines, and this decision is an "analog computation" made by a massive scale hybrid computer that no one has intentionally designed or understands.
You can see examples of this already, with youtube recommendation engines influencing the belief systems of millions (billions?) of people across all kinds of subjects, and with our thoughts frequently dominated by whatever happens to show up on our phones.
Let's try imagenet training. Intel's best time is 3h25m on 128 nodes. Imagenet is ~150 gb.
(150 GB)/(3 hr * 3600 sec/hr * 128 nodes) = less than one megabyte per second per node! Caffe is slow! CPUs are slow!
Or bs metrics are bad?
What problem do you think having a standard ISA would solve? Nobody distributes native binaries for GPUs, only shaders (either compiled to intermediate representation or no). From my perspective, all that a standard ISA would cause is less implementation flexibility in the hardware since now the hardware has to deal with compatibility instead of letting the vendor-specific compiler included with the driver deal with it.
If a TV breaks now, it's some component that's either glued in or soldered in, so good luck replacing that. Modern TVs are not designed to have replaceable parts.
You can see what spacex (probably) does to turn it into a tractable problem for real time control in http://www.larsblackmore.com/iee_tcst13.pdf (Blackmore leads entry, descent, and landing at spacex).
> If you read the papers you need a very specific construct in order to not only cause a speculative load of an address you choose but also to then manage to cause a second operation that in some way reveals bits of data or allows you to ask questions.
> BPF allows you to construct those sequences relatively easily and it's the one case where a user space application can fairly easily place code it wants to execute in the kernel. Without BPF you have to find the right construct in the kernel, prime all the right predictions and measure the result without getting killed off. There are places you can do that but they are not so easy and we don't (at this point) think there are that many.
> The same situation occurs in user space with interpreters and JITs,hence the paper talking about javascript. Any JIT with the ability to do timing is particularly vulnerable to versions of this specific attack because the attacker gets to create the code pattern rather than have to find it.
---
> big deal with spectre is the high bandwidth that can be attained by directly running code in process
That depends on your perspective. If you are an OS developer who strives to guarantee process isolation, than it is a pretty big deal that spectre v1 allows you to read memory from the kernel or from other processes, even if it might be tricky to do so. If you write a JS JIT, then yeah you are probably most concerned about the single-process case.
> remotely practical
IMO, most spectre attacks are not remotely practical. No, I don't have a pointer. The only actual demonstrations of spectre I've seen is the one included with the original paper (single process).
I don't think this is true. If it is, why did Linux add speculation barriers to bounds checks in the kernel?
I was in a discussion of this last week on another thread - see my previous comments for why I think spectre v1 has impact across processes.
In terms of the possibility of exploit, as I understand there isn't at this point any isolation between processes.
In terms of the ease of exploit, being able to run untrusted code in the same process as the victim helps quite a bit. Otherwise, you have to find a gadget (i.e. qualifying bounds check for v1, indirect branch for v2) in the victim process that you can exploit from the attacker process. Possible, but quite a bit harder than making your own gadget.
This all ignores the forward looking reasons process isolation is a good idea. I can't keep track of the latest mitigations in Linux, but they pretty much all will only help between processes by flushing various hardware data structures. And hopefully someday we will have hardware actually designed to restore the guarantees of isolation between processes.
I'm pretty sure this is accurate, but I'm just a random guy on the internet so don't trust my word for it too much.
For spectre v1 and v2, right now (on existing hardware) mostly nothing separates threads from processes. In the future, process isolation is a good candidate for designing hardware + system software such that different processes are isolated (via partitioning the caches, etc).
You probably still want threads within a process to share cache hits.
It's worth noting that no existing or announced common hardware is "properly designed" according to this condition. Even the "fixed" Intel hardware that's been announced is still vulnerable to spectre v1 across process boundaries.
3D graphics? Check (freebie).
Fluid dynamics? Check - supercomputers increasingly get most of their compute from GPUs.
Cryptography? Check - this is the only one that really got specialized hardware.
Machine learning? Check.
So "large quantities of special purpose hardware" wasn't even used for these. Just large quantities of general purpose parallel processors, known for historical reasons as "graphics processing units."
I'm all for skepticism for the current hyperbole, but there's no need to be hyperbolic in the other direction.
There are some applications in which deep learning really does work better than alternatives. The 2018 Gordon bell prize, after all, went to a team that did deep learning on Summit for climate analysis.
There is a nontrivial list of applications that you would have a hard time convincing experts that they would be better off with conventional code.
If only 2% of women over age 16 as also under age 18, that statistic is not so shocking. I don't agree that this statistic alone demonstrates that "almost all women were married between 14-16."
"A study in scarlet" is not historically accurate. IIRC, Conan Doyle said so himself.
Maybe, maybe not, but the async compute argument you are making only applies to graphics applications that use compute shaders on maxwell - it doesn't apply to pure gpgpu without graphics.