An unexpected perf feature

Posted May 22, 2013 20:50 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: An unexpected perf feature by dgm
Parent article: An unexpected perf feature

"Safe language" is actually well-defined. It means a language where it's impossible to cause memory corruption, which is certainly possible.

to post comments

An unexpected perf feature

Posted May 23, 2013 9:17 UTC (Thu) by dgm (subscriber, #49227) [Link] (6 responses)

There's no way to prevent memory corruption, as long as I can write to the wrong variable (ooops!). Memory protection is a feature of the underlaying machine, not the language.

An unexpected perf feature

Posted May 23, 2013 12:32 UTC (Thu) by renox (guest, #23785) [Link]

Uh? Your definition of memory protection is different from the normal definition which makes your post quite useless..

An unexpected perf feature

Posted May 23, 2013 12:46 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Write a wrong value _where_?

And yes, it's totally possible to create a language (hint: Java, C#) that do NOT require hardware memory protection at all to isolate misbehaving applications.

An unexpected perf feature

Posted May 27, 2013 17:13 UTC (Mon) by dgm (subscriber, #49227) [Link] (3 responses)

> Write a wrong value _where_?

Anywhere it was not intended to be, but mostly strings, specially strings that are interpreted by the program.

> And yes, it's totally possible to create a language (hint: Java, C#) that do NOT require hardware memory protection at all to isolate misbehaving applications.

It's not the language but the virtual _machine_ they run on what isolates misbehaving applications.

An unexpected perf feature

Posted May 27, 2013 23:51 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> Anywhere it was not intended to be, but mostly strings, specially strings that are interpreted by the program.
That won't cause memory damage.

> It's not the language but the virtual _machine_ they run on what isolates misbehaving applications.
Nope. If your language allows unrestricted pointer arithmetic then it doesn't matter at all if you are running it inside the most secure VM.

And if your language simply doesn't have a way to express pointer arithmetic then you can't use it to do memory damage.

An unexpected perf feature

Posted May 28, 2013 8:59 UTC (Tue) by etienne (guest, #25256) [Link] (1 responses)

> And if your language simply doesn't have a way to express pointer arithmetic then you can't use it to do memory damage.

IHMO you can't use that language to manage the memory neither, i.e. you can't write malloc()/free() nor what the kernel needs, for instance "allocate a contiguous DMA able buffer accessible with DMA32 PCI card and fail if a wait is needed and give back it's physical address" or "free memory blocks after DMA hardware has finished sending them", or any variation of it.
Obviously if you had perfect hardware and a processor with an "allocate_memory" and a "free_memory_after_both_software_and_DMA_have_finished_with_it" assembly instruction, then maybe...

An unexpected perf feature

Posted May 28, 2013 9:06 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

You can certainly do it. You won't be able to do free() unless you can statically prove its correctness, but doing malloc() and using GC to collect unused objects is possible.

You also certainly can allocate buffers with special properties, and you can even do stuff like reading from within buffers by using fat pointers (i.e. a pointer with a length).

In fact, it's all been done in the past even for OS kernels. It's the question of practicality, not possibility.