
Writing a dynamic x86_64 assembler in Scala - guillaumebort
https://github.com/guillaumebort/scasm
======
xaduha
Quick intro to x86_64 assembler, FOSDEM presentation:

[http://video.fosdem.org/2016/h2214/amd64-assembly-
programmin...](http://video.fosdem.org/2016/h2214/amd64-assembly-programming-
for-perl-programmers.mp4)

[https://github.com/bdw/lab/tree/master/asm](https://github.com/bdw/lab/tree/master/asm)

------
vans
I saw the talk. It was a nice hack !

------
electrum
For a more complete x86 and x86_64 assembler for JVM languages:
[https://github.com/jnr/jnr-x86asm](https://github.com/jnr/jnr-x86asm)

------
dkopi
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.

~~~
userbinator
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. :-(

~~~
dkopi
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.

~~~
junke
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?"

~~~
dkopi
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?

~~~
sbuttgereit
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.

~~~
dkopi
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.

------
aiglon
Is the generated code really faster? Or what is the point of this?

~~~
guillaumebort
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.

~~~
aardvark179
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.

