Re: DSO-style FFI

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 09 Oct 2013 17:52:36 -0600 Davis Herring <herring@lanl.gov> wrote: 

>> That's pretty dangerous, isn't it?  Any memory corruption, intentional
>> or not, could affect the user significantly.  Is that an acceptable risk?

DH> Intentional memory corruption is entirely beside the point -- you're
DH> already planning to run whatever code the DSO provides with your current
DH> security credentials.  (You even already run DSO-specified code as soon
DH> as you call dlopen().)

OK.

DH> As for accidental corruption, you can at least protect your Lisp_Objects
DH> by controlling how you copy data into and out of them.  (Of course, a
DH> wild pointer can corrupt absolutely anything, but you're not very likely
DH> to be in an undesirable "Emacs appears functional but is confused" state.)

Yeah, I was wondering how much can be done here, but I guess "not much."

Moreover, I was wondering whether the risk is acceptable.  The other
extreme is to have some protocol to externally executed modules so
there's no chance of corruption; it's very inefficient but also much
less risky.  I think it's safe to say the risk of DSOs is acceptable to
everyone, but wanted to be clear about it.

Thanks for explaining.

Ted