Very good news from AMD, will make GPU mining kernel development easier
-
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.
