[erlang-questions] Erlang VM in Rust

[Peer Stritzinger]

If you are not aiming at super small hardware but lets say in the 100-300 MHz 32bit controller range there is
another way to protect agains C problems at least in the application domain:

Running Erlang directly on the hardware as we do frees the Translation Lookaside Buffers that are used for
virtual memory.  These small chips have some which allows very inefficiently to run Unix alike systems.

If we use those VM features to jail in the C code in a NIF it can’t escape its little box.

Therefore we can use Erlang and safe C NIFs on these embedded systems without the overhead
of Unix alike OS, full virtual memory and OS processes.

That eliminates trusting the application level C code.  Unikernel and Erlang VM remain though.

Best,
-- Peer 

> On 22.09.2017, at 16:33, Joe Armstrong <erlang@REDACTED> wrote:
> 
> You're quite right  C is memory unsafe, and the large quantity of C code
> in IoT devices is as you rightly say a disaster - only it has already happened
> no waiting is involved.
> 
> I would like to *reduce* the amount of C - write an emulator for language X
> in C, then write everything in X. X would be a "better" language than C
> in some sense. X should compile to a small instruction set such that
> the implementation of the VM would be a simple and hopefully correct program.
> 
> if we go back to the P-code machine the design was very simple and the
> implementation a few hundred lines of pascal (or C) - I'm pretty sure
> one could write a memory safe P-code interpreter in a memory-unsafe
> language like C.
> 
> Security (since you mentioned it) ultimately relies on trust. Do you trust the
> compiler? do you trust the programmers? Do you trust the hardware?
> 
> If I were building a secure system I would try to trust as little as possible
> putting firewalls and checks between components.
> 
> Given a pure choice between a language that offered memory safety
> and one that did not I'd obviously choose the memory-safe language
> all other things being equal.
> 
> Trouble is all other things are not equal.
> 
> For me:
> 
> Time to solve problem =
>   Time to understand problem (T1) +
>   Time to learn language X (T2) +
>   Time to write program in X (T3)
> 
> If I choose C then T2 is very small. Usually T1 >> T3.
> 
> The "elephant in the room" is the time to be productive and know the
> idioms of programming in X.  T3 is small when you are proficient
> in the language otherwise large.
> 
> I have said before - I think it takes about 3 weeks to learn a language
> 6-24 months to know your way around the libraries and 10+ years to know
> how to solve a problem in your favorite language.
> 
> I dabble with new languages, not to become productive in them,
> but to see what new ideas they embody.
> 
> Niklas Wirth said many years ago that it was far better to be very good at one
> language than having superficial knowledge of many.
> 
> Cheers
> 
> /Joe
> 
> 
> 
> On Fri, Sep 22, 2017 at 2:39 PM, Anthony Ramine <n.oxyde@REDACTED> wrote:
>> Joe you are still ignoring the elephant in the room that C is a memory-unsafe programming language and that you are suggesting putting it in IoT stuff. That's a security disaster waiting to happen.
>> 
>>> Le 21 sept. 2017 à 22:37, Joe Armstrong <erlang@REDACTED> a écrit :
>>> 
>>> I'd like to make an extremely small extremely slow Ertang targeted to
>>> IOT devices - low power devices with small memory and slow clocks.
>> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions