Question and proposal: Can D be used to compile and run untrusted plug-ins?

[Moamen Abdelsattar]

On Saturday, 4 December 2021 at 12:18:23 UTC, Dukc wrote:
> The same can be accomplished by sandboxing the compiled binary 
> somehow though. For example, D program compiled to WebAssembly 
> cannot corrupt the web browser running it, just like no 
> WebAssembly program can (modulo browser vulnerabilities).

I'm aware of that way of sandboxing, but it's not as efficient. I 
mean you can't call the functions inside the plug-in directly 
with C calling convention. If you need to call it thousands of 
times, the application will be markedly slower.
Also I think that passing structures or objects with overriden 
virtual functions to the application will be a difficult problem 
due to ABI incompitability.

> 1: It only guards against memory integrity violations, not 
> against otherwise
> malicious system calls.

Yes but I think memory-safe code can't do anything outside the 
API. Malicious C code (that is not linked to system calls) can 
still use pointer arthmetric to make system calls by address, use 
inline assembly to make them, or write to data segment to change 
the application's behaviour in a certain way. Making the 
untrusted code memory-safe will also make it safe to execute if 
it's only linked to a secure API.

> 2: The more difficult problem. It is not bug-free enough.

That's disappointing, but at least it can make malicious code 
more difficult to write; it's better that nothing, and 
vulnerabilities can be fixed by time.