acoye

Google security blog says it is.

> These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them.

https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...

Yes, I knew you could do rowhammer on arm too where clflush does not exit. So rowhammer is not the correct example. Yet at some point it was believed that it was necessary on x86 for the attack to work. https://en.wikipedia.org/wiki/Row_hammer#Exploits

I just made a bet that I could guess something out of ISA only. Going macro to describe what may be the issue. I'm just doing a guess work here.

I was not implying Intel has the same implementation as AMD, nor I was making a case for "this is like rowhammer"

It is not, but if like it was the case for rowhammer, it was linked to a specific instruction (clflush).

This time it could be an AVX512 instruction (intel only) that leaks kernel address in a way or another.

I was talking from an ISA perspective. For eg, clflush may be implemented differently between Intel and AMD, it has the same effect on system RAM hence a shared exploit.

Do you think this could be within the rather new Intel AVX 512 ISA or older intel CPUs like Sandy Bridge (first AVX chip) could also suffer?

- edit - I checked Ryzen ISA, they support AVX2. So probably AVX512 is the issue.

Ok so all I hear is Intel and no trace of AMD? So X86_64 ISA wise the only diff between modern CPUs are AVX512.

I bet you within the foundations of AVX512 lies a nasty one that can't be patched with microcode update.

I would like to know too. I know some PoS coins are there but I do not know of existing validator pools.

True, and it happened recently to NiceHash. Yet the miner looses a portion of generated cash, not the capital (here GPUs)

It feels a bit more risky than mining in a pool don't you think? If a validator pool is hacked you loose your stake.

The equivalent in PoW world would be someone breaking in and leaving with all the GPUs of all the users of a pool, what I would consider not dooable for a large enough pool.

I'm reading the paper looking for an answer. (as I'm hopping to be able to run a PoS node in the future)

As I understand PoS, for security to be achieved, you need to be able to lose a non trivial amount of ether. I guess the 1K5 ETH is designed to stay roughly above 1 million USD of stake.

Yeah, why would smaller holders of ether would be excluded from PoS? Security probably. But it sucks that the small holders cant profit from their property.

Maybe there is a need to create a "cooperative" of sorts hodling the eth of many users and running PoS thus rewarding the owners. (like a pool but safety would be way more of an issue compared to PoW)

Yeah, their tech is useful to the industry, that said the coin is a liability for a bank.

I see a future where banks exchange value with 1coin=1USD to speed up transactions but not using the value of XRP.

Plus for a random user making an investment, XRP not been a public blockchain is a no go for me.

They can hardfork / print money as they please.

• Write a blockchain in swift

• Learn to write Ethereum dapps

• Tinker with modern GPUs on my QuadG5 under Linux.

I would like to argue Bitcoin has a fundamental. The number of people using it and making up its value.

`Metcalfe's law states that the value of a telecommunications network is proportional to the square of the number of connected users of the system (n2)` https://en.wikipedia.org/wiki/Metcalfe%27s_law

He may be biased, but you may be too. Are you a Java developer (or android)?

That said, I know some great software can be produced in Java, ElasticSearch been one on top of my mind.

If Security is the goal, nor CPP nor Java is great. Proven Haskell or Rust might be more of a valid option.

We now can engineer a forest like in Avatar. I like this idea.

I am not, Yet given the public disclosure and the criticality of the issue, they took the most pragmatic approach.

if tf runs most of the workload GPU side, SSE enabled binary is less compatible and no longer a bottleneck.

I see a couple of issues with the Mac / TF OpenCL situation.

Apple is pushing metal and performance shaders, I would not bet on strong support from them keeping up to date drivers with performant ocl. I asked at wwdc17 about vulkan and they clearly do not want it on their platform.

The TF OpenCL issue is vocal on the repo. Yet to see progress for macos. https://github.com/tensorflow/tensorflow/issues/22

Last but not least there is an issue with the ocl support. It is (was?) done on linux using computeCPP, compiled to SPIR (Standard Portable Intermediate Representation). MacOS does not support SPIR at the moment.

My best guess would be to use IOMMU magic and hardware virtualization to hook a GPU to a linux VM with MacOS as a host.

Yes you are right, no causation just a funny correlation.

With Google's new war on Intel's ME this is not a coincidence.

I've been using it (beta) for a while on a win10 desktop. No perf issues to report. Launch time is now on par with others.

I'll consider going back from chromium to FF on macOS after the mainstream release.

Happy to see some love going on for ff, which I used to love back then, BC (before chrome) era.

It may works as a stopgap as this extreme move is not usualy found in games where performance is key to the experience.

Hackers will develop better tooling for VM introspection or something in the near future dropping again the time between release and initial anti-drm patch.

As a concerned consumer who buys game on pc or ps4, knowing this I will pass on the PC version and buy a second hand PS4 version.

No way I'm upgrading my 3570k for the sake of a pointless virtualization overhead.

If someone did a nicely readable epub out of it, I'd be a happy reader.

The end of x86 32bit is near … And here I am trying to find an up to date distro for my G5s :D

Tl;dr opensource or not, market share dictates supported archs.

The only difference been, you can try to build from the sources for your vintage hardware.

I guess ARM is safe for now … Is it not?

I saw it coming when they discontinued Joule and Galileo.

I actually liked the Curie chip, plenty of goodies in one die. From bluetooth LE to battery charger to accelerometer and gyro plus hardware acceleration for k nearest neighbor (cool for gesture recognition). All that on small form factor low energy die.

Plus, I _feel_ safer using a curie for IoT than just using a raspberry pi and never updating a linux distro.

https://hackaday.com/2017/06/19/intel-discontinues-joule-gal...

Is the code available somewhere? It doesn’t look like to be open-sourced.

Hey, I'm Adrian. I did the 'More colors' shader.

Given the nature of the project, a hackathon, sticking to the last computed FFTs and a notion of time was all we need to play with nice shader effects.

I'm currently playing with tensorflow on my spare time. I'd like to use a neural net to find interesting features of a track and inputting this to a shader. That's what I would do if I had another go at it.

> Jules Verne […] who would never educate you too make Nitro Glycerin. /S

Haha also fulmicoton between other things. Love these books and the pragmatic approach to solve the problem at hand.

Would prevent Rowhammer attacks.