Writing a dynamic x86_64 assembler in Scala(github.com)
github.com
Writing a dynamic x86_64 assembler in Scala
https://github.com/guillaumebort/scasm
21 comments
I saw the talk. It was a nice hack !
For a more complete x86 and x86_64 assembler for JVM languages: https://github.com/jnr/jnr-x86asm
While very(!) cool as a proof of concept,
This type of solution should probably be avoided for security, stability and portability reasons.
Allowing a string in your program to be dynamically converted to assembly code, copied to executable memory and be executed is a remote code execution security hole just waiting to happen.
I'm wondering what the use cases for this were, and if they couldn't be achieved in another way.
Allowing a string in your program to be dynamically converted to assembly code, copied to executable memory and be executed is a remote code execution security hole just waiting to happen.
I'm wondering what the use cases for this were, and if they couldn't be achieved in another way.
Seriously? It says a lot about the direction computing is going when one of the first things someone says upon seeing one of the most powerful and amazing things you can do with a general-purpose computer is some fearmongering about a "remote code execution security hole". The "oppose anything that could possibly be used in some way someone doesn't like" attitude is why computers have become so user-hostile. :-(
Protecting the safety, security and privacy of users isn't "user-hostile".
Leaving your users exposed to hackers, viruses, malware, malicious adware, ransomware, government espionage and bot networks is.
I find it completely baffling than in 2016, people can still refer to writing secure code as "fearmongering".
Being able to dynamically inject code into your process and run it is indeed very powerful. But i'll cliche quote spiderman about great power, and insist that if you're going to execute "mprotect" or "VirtualProtect", make sure the code you're about to execute is signed and verified. Not doing so, would be user-hostile.
I find it completely baffling than in 2016, people can still refer to writing secure code as "fearmongering".
Being able to dynamically inject code into your process and run it is indeed very powerful. But i'll cliche quote spiderman about great power, and insist that if you're going to execute "mprotect" or "VirtualProtect", make sure the code you're about to execute is signed and verified. Not doing so, would be user-hostile.
Sure, this is a valid concern, but in the context of a learning experiment like the one discussed here, this is not really important.
"Hey kid, nice treehouse, but what about burglars?"
"Hey kid, nice treehouse, but what about burglars?"
"Hey kid, nice treehouse, but what about burglars?"
Also building code, fire code, ADA accessibility requirements and permits and sign off.
Also building code, fire code, ADA accessibility requirements and permits and sign off.
From the scasm readme.md: "Do not ask for the final goal of this: this is more a learning vehicle to abord several interesting topics."
Isn't security one of those interesting topics?
It can be... but it also can be a drag if that's not your immediate area of study. Security is incredibly important, but it is an overhead: including a cognitive overhead. If I'm futzing around with a toy project to learn about how, say, distributed agents can make use evolutionary selection to create efficient protocols amongst themselves (yes, a completely bullshit set of terms strung together) and I fully expect this to never leave a group of VMs on a home server.... yeah, security is NOT something I'm going to sweat. Doing so would be a distraction and counter-productive to my goals.
To be fair to your point, however, by not constantly practicing secure coding techniques, regardless of context, I could get out of the habit of secure coding as a default. I may simply not think about it at a time when I should be. By always considering, even in my bullshit toy project, I stick to my good practices and more consistently apply them when it counts. But the argument that security coding can be interesting and fun is not a good enough argument to care about it all the time.
To be fair to your point, however, by not constantly practicing secure coding techniques, regardless of context, I could get out of the habit of secure coding as a default. I may simply not think about it at a time when I should be. By always considering, even in my bullshit toy project, I stick to my good practices and more consistently apply them when it counts. But the argument that security coding can be interesting and fun is not a good enough argument to care about it all the time.
I'd argue that all code should be fairly defensive.
Security flaws in the end are just bugs. And defensive programming helps reduce bugs.
As for toy projects - you never know when your futzing around becomes a full blown product.
Obviously, security is always a tradeoff. I'm not suggesting you implement 2 factor authentication for your wedding invite website. But it does always help to consider: 1. How can this code break, if someone accidentally misuses it? 2. How can this code break, if someones intentionally misuses it?
Very often, thinking about #2 can help resolve a lot of things overlooked in #1.
Obviously, security is always a tradeoff. I'm not suggesting you implement 2 factor authentication for your wedding invite website. But it does always help to consider: 1. How can this code break, if someone accidentally misuses it? 2. How can this code break, if someones intentionally misuses it?
Very often, thinking about #2 can help resolve a lot of things overlooked in #1.
> The "oppose anything that could possibly be used in some way someone doesn't like"
Could you please show me a person who'd like being the subject of remote code execution?
Could you please show me a person who'd like being the subject of remote code execution?
I agree with you, doing this breaks almost all the advantages you have using a JVM in the first place. So you probably don't want to hack this way.
There was no real use case for trying this. Just to see if it would be possible. As you say it is just a proof of concept.
There was no real use case for trying this. Just to see if it would be possible. As you say it is just a proof of concept.
> I'm wondering what the use cases for this were, and if they couldn't be achieved in another way.
I suggest you click on the link and read the words written on that page.
I suggest you click on the link and read the words written on that page.
You're right. missed the "Do not ask for the final goal of this: this is more a learning vehicle to abord several interesting topics." at first. You'll see I addressed this later on in the thread.
I tend to skim through the readme and dive in to the code when evaluating stuff on github.
Is the generated code really faster? Or what is the point of this?
Well for this specific `add` function, no it won't :)
The hotspot compiler will generate the same code anyway (perhaps even more optimised if it is possible I don't know). Worse, this code would probably be inlined while the `native` version won't.
The hotspot compiler will generate the same code anyway (perhaps even more optimised if it is possible I don't know). Worse, this code would probably be inlined while the `native` version won't.
Not only will the native version not be inlined, the JIT will also have to insert an annoying amount of stuff round it to handle calling conventions and other fun things.
http://video.fosdem.org/2016/h2214/amd64-assembly-programmin...
https://github.com/bdw/lab/tree/master/asm