Very good news from AMD, will make GPU mining kernel development easier
-
One of the “challenges” of FTC being an “open source” DAO, is hardware and firmware are closed source.
This creates problems, when proprietary and open source collide. For instance, when FTC converted back to ASIC incompatibility, various members contributed to the development of open source mining software, including cash for miner software and improvements to the Neoscrypt algorithm to run on GPUs.
These and other further “improvements” were retained for the community, would have otherwise gone to a private mining farm. Where a farm can have a more efficient proprietary driver, is like having an ASIC when all other miners are using a CPU or GPU with much less power. It makes it easier, cheaper and tempting to try a 51% attack on a block.
After that, a worse situation developed where some coins kernels were released as closed source bins, to further “hide” how the improvements were acheived by the GPU kernel programming specialist. Closed bins are an obviously also a serious security risk, that I would never use.
It is important to be able to refine the GPU kernel software, especially if a new model of GPU is launched with additional features. Increasing in the hash rate does increase the security of that block’s encryption.
I already can see that AMD, are already supporting opencl, which has helped stimulate open source machine learning software that can run on GPUs. It is an obvious “strategy credit” to AMD that they can exploit against nVidias proprietary CUDA.
AMD, by announcing it is going to produce open source drivers it is evident that the development of open source kernels, for such as FTC’s Neoscrypt, will also be simplified. This gives the community at least all the tools to maintain and gradually improve software such as, sgminer.
Very good news.
AMD Announces GPU Open Initiative, New Compiler And Drivers For Lunix And HPC
http://www.pcper.com/reviews/Graphics-Cards/AMD-Announces-GPUOpen-Open-Sourced-Gaming-Development
What is OpenCL?
OpenCL is a standards-based programming language that allows the CPU and GPU to work together for faster and more efficient processing.
-
Thankfully this is happening, as I tried a few times over the last few days to get sgminer working with a 280X and it keeps spewing HW errors and no accepted work. Until the process is somewhat easier, I will just wait to turn the miners back on as i assume many others are also doing.
-
sgminer should be working to mine Neoscrypt coins,
what was your other hardware?, did you compile the linux version from github from the guide? Did you include the correct driver dlls for the windows version?
-
It is likely the driver dlls that i am missing. I have the current fully upgraded drivers as it is my gaming rig. I no longer have standalone mining rigs and figured i could do some hoby mining again here and there.
-
Just a note on what is the future for “improving mining efficiency”, I have seen that a new hardware device type called a “Crypto- Accelerator” has just come out.
It is used accelerate encryption and decryption of messages, so companies can check all the encrypted traffic going in or out the company network, or to speed up big sites where everything is now ssl…
It’s seems obvious that such a device has the potential to be leveraged as a programmable generic ASIC and would only need software (sgminer) to send and receive the encryption / decryption results to a crypto-accelerator instead of what is handled currently by the neoscrypt.cl GPU kernel.
-
I’d love to hear the rationale behind bins being a security risk - they’re not “obviously” a risk. As a matter of fact, it’s a LOT better for the end user - because plenty of end users either don’t know how to find and install specific versions of AMD drivers and/or install only the latest. Every other or maybe every third driver, AMD manages to utterly destroy what little quality their OpenCL compiler has - and sometimes fails to fix it for a few versions. Now, the binary helps because it was compiled by the CODER’S driver, meaning less on the user.
Oh, also, because of aforementioned terrible OpenCL driver, I now often drop to AMD GCN assembly language - what source would you have me release?
-
@wrapper said:
Just a note on what is the future for “improving mining efficiency”, I have seen that a new hardware device type called a “Crypto- Accelerator” has just come out.
It is used accelerate encryption and decryption of messages, so companies can check all the encrypted traffic going in or out the company network, or to speed up big sites where everything is now ssl…
It’s seems obvious that such a device has the potential to be leveraged as a programmable generic ASIC and would only need software (sgminer) to send and receive the encryption / decryption results to a crypto-accelerator instead of what is handled currently by the neoscrypt.cl GPU kernel.
Not the case. The algos used in Neo are NOT likely to end up in a crypto-accelerator, and on top of that, it’s not magic - you’re not going to get it to ever do Neoscrypt, you’d have to have it do the pieces of Neoscrypt and then do the rest on CPU/GPU. For example, have the accelerator do Blake - but still, this wouldn’t have too much of an effect even if you did the core algos, I think - you’ve got the memory usage to contend with.
-
Hi Wolf, interesting to hear you’re opinion.
I think you are limiting your vision of what might happen in the future.
I’m not predicting this but, after all, FTC has changed algorithm once, so it doesn’t have to be Neo, it could be CryptoNeo.
Correct, it would be another hard fork, but again, that could be on 75% vote at some time well in the future. Plus, the thread was started to promote discussion …
@Wolf0 I’d love to hear the rationale behind bins being a security risk
I’d be glad for you to explain otherwise but, binary files are highlighted as potential security risks because compiled bins could contain other code and you don’t know, unless, either, you have the source code or are able to decompile them.
Assembler, compilers and microcodes are also highlighted as similar risks and as you point out, they don’t have 'readable" source with assembler, so it is even harder to audit.
-
I get it - you’re using the a (usually valid) point, and you don’t see how it doesn’t quite apply the same way.
To understand why it’s not really much of a risk at all requires understanding the difference between the host and device when it comes to GPU acceleration. The host is your PC, the device its GPU. For all intents and purposes, they are completely seperate computers connected over the PCI-e bus. Now, if you ran a binary-only executable on the host, you’re absolutely correct in that this is a security risk and it can abuse your system. In the device’s case, however… well, let’s pretend I’m malicious:
I want to do something bad, but here’s how it has to happen - the kernel(s) called must be called from an open source application. The memory it uses must be allocated by the same, and passed to the kernel(s) that need it by the same. It also is expected to give a certain correct output (finding correct nonces) - if it does not, the game is up; obviously no miner will sit and run a kernel that doesn’t find any shares! Now, maybe I compute something extra for me on the side, eh? How do I get the data off the GPU? If I try using the open source application, it’s obvious. I have no access to the PCI-e shit through compute, and even if I did, the worst I could do is maybe DMA it to somewhere in memory… which I then cannot retrieve undetected because of the open source host code. I have no options.
-
I don’t want to give any ideas, but you are perhaps being over ambitious, the NSA might just gradually leak a key?
You are correct it would be harder to exploit than a plain binary, but I have seen and run other code in the GPU .
-
This is an interesting development …
-
@wrapper said:
I don’t want to give any ideas, but you are perhaps being over ambitious, the NSA might just gradually leak a key?
You are correct it would be harder to exploit than a plain binary, but I have seen and run other code in the GPU .
I have a really hard time posting on this new forum - often the little pop-up for creating/editing a message doesn’t come up. I don’t know about Nvidia, but I know AMD, and specifically AMD GCN, in quite deep detail. Leak what key? What kind of key? The only thing you could possibly leak off the GPU would be the winning nonce, and even that has zero value - the open source miner code will submit it to the pool or to the network (in the case of solo mining) immediately.
But let’s pretend I could access every possible bit of the GPU - I have DMA access to memory, MAYBE, over the PCI-E bus. That’s about the fuck it - now, ehhh… maybe I could clobber some important OS structures like the EPROCESS (executive process block) doubly linked list in Windows, but that’s IF I can (ab)use DMA to read/write to kernel mode, which I kinda doubt, ever since that vuln was found that abused DMA with FireWire devices (I think) to access privileged memory. This would allow me to crash the OS - basically a denial of service - but it could be fixed with a reboot, and then they wouldn’t run the miner again.
Now, this is probably impossible since I can’t access the PCI-E capabilities of the card from a compute kernel - but even if I could, I wouldn’t have to in order to crash Windows. The AMD driver is so bad that I could lock up or outright cause a bug check (BSoD) in Windows simply by writing all over invalid GPU memory from the kernel - and this will happen on Linux too; these users are not exempt. I’ve done it by accident.
In any of these cases, the user reboots, and they don’t run that miner or GPU binary again, because it produces quite obvious undesired operation that interferes with their normal use of the system. There’s no wiggle room for malice here.
-
Don’t worry about it Wolf, it’s a specialised software, so unlikely to be targeted any way.
As you know with security, just being able to cause a crash, maybe by a spear fished or whatever, could let someone in. That’s unlikely to work if the miner is on separate secure PCs. But we are talking about decentralised “mining money”, so it should be considered a target
As you probably understand, my main aim is to make the software open, not accuse you of inserting a trojan…
P.S. Thanks for the other info, which areas of hardware are secured and what the GPU can and can’t do is an interesting subject …
-
@wrapper said:
Don’t worry about it Wolf, it’s a specialised software, so unlikely to be targeted any way.
As you know with security, just being able to cause a crash, maybe by a spear fished or whatever, could let someone in. That’s unlikely to work if the miner is on separate secure PCs. But we are talking about decentralised “mining money”, so it should be considered a target
As you probably understand, my main aim is to make the software open, not accuse you of inserting a trojan…
P.S. Thanks for the other info, which areas of hardware are secured and what the GPU can and can’t do is an interesting area…
Not a problem; and don’t worry - I didn’t take it personally. I’m just saying I personally would feel comfortable (and I don’t see why anyone wouldn’t) in running (for example) Kachur’s X11 GPU binaries with my own host code - even though it was found his miner was exploiting pools to look faster in the case of XMR (I think it was XMR.)
On the other paw, I disassembled and modified the GCN assembly, then reassembled it before running it - but this wasn’t for security purposes; I simply wanted to improve the speed of the X11 code.
