unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Michael Welsh Duggan <mwd@md5i.com>
Cc: Tom Tromey <tromey@redhat.com>,
	emacs-devel@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
	jerry.james@xemacs.org
Subject: Re: DSO-style FFI
Date: Sun, 13 Oct 2013 08:36:20 +0900	[thread overview]
Message-ID: <87k3higiyz.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <87wqlitse5.fsf@maru2.md5i.com>

Michael Welsh Duggan writes:

 > As an example, it would be possible to use a raw libffi binding to call
 > memset with appropriate arguments to tromp right over any memory that
 > emacs has access to.

Sure.  But this requires a bit of knowledge of C APIs.  With a tiny
bit more knowledge of C and a dollop of cargo cult, one can use
Stefan's interface to do the same thing, compile it, load it, and
crash or corrupt Emacs.  One could even write Lisp that writes most of
such a program.

 > This isn't to say that something that is not libffi itself could
 > use libffi to create something safer.

No, you can't, in practice.  That would require all libraries to be
safely coded (in the sense that memset is not).  You would need to
exclude linkage to unsafe APIs, but that would be very hard to do (how
about calling PNG editing facilities on an uninitialized piece of
memory that happens to already contain Emacs code or data?)

As for RMS's freedom concern, he's already stated what would be
acceptable: create an Emacs-side API requirement in its FFI
implementation that the DSO declare its GPL compatibility (including
version, I assume).  If the API isn't present, dlopen() will fail,
AIUI.  If the API doesn't declare a compatible set of versions, the
FFI implementation will refuse to bind Lisp to the DSO and unload it.

Note that this is actually quite effective as far as I can see.  If a
DSO is being commercially distributed under false pretenses at the API
level, that's not just a copyright violation, it's fraud.  This means
that there's a good chance that not only the FSF (as owner of the
copyright to Emacs), but also the customer (victim of fraud) and the
relevant government authorities (since fraud is a crime) have standing
to take action against the perpetrator.  (Copyright violation in
general is a tort, not a crime, so the FSF as owner needs to take
action.)  IANAL, etc, but if RMS and the FSF's legal staff are in
agreement that this is good enough, I'm willing to bet it is. :-)






  parent reply	other threads:[~2013-10-12 23:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-06  9:15 GNU Emacs-libnettle-libhogweed integration patch v1 Ted Zlatanov
2013-10-06  9:58 ` bignum support in Emacs with libgmp (was: GNU Emacs-libnettle-libhogweed integration patch v1) Ted Zlatanov
2013-10-06 16:09 ` GNU Emacs-libnettle-libhogweed integration patch v1 Eli Zaretskii
2013-10-06 21:07   ` Ted Zlatanov
2013-10-06 16:51 ` Stefan Monnier
2013-10-06 16:58   ` Eli Zaretskii
2013-10-06 21:19   ` Ted Zlatanov
2013-10-07  4:02     ` Stefan Monnier
2013-10-07 11:41       ` Ted Zlatanov
2013-10-07 22:03         ` Ted Zlatanov
2013-10-07 22:58           ` Stefan Monnier
2013-10-07 23:43             ` Emacs crypto use cases (was: GNU Emacs-libnettle-libhogweed integration patch v1) Ted Zlatanov
2013-10-08  3:02               ` Emacs crypto use cases Stefan Monnier
2013-10-08 10:33                 ` Ted Zlatanov
2013-10-08 13:17                   ` Stephen J. Turnbull
2013-10-08 16:35                   ` DSO-style FFI (was: Emacs crypto use cases) Stefan Monnier
2013-10-08 17:32                     ` DSO-style FFI Tom Tromey
2013-10-08 19:42                       ` Ted Zlatanov
2013-10-08 20:43                         ` Tom Tromey
2013-10-09 23:21                           ` Ted Zlatanov
2013-10-10  8:09                             ` Andreas Schwab
2013-10-08 20:47                         ` Davis Herring
2013-10-09 22:26                           ` Ted Zlatanov
2013-10-09 23:52                             ` Davis Herring
2013-10-10  1:25                               ` Ted Zlatanov
2013-10-10  4:36                                 ` DSO-style DSOs (this is NOT an FFI!) Stephen J. Turnbull
2013-10-09  1:48                       ` DSO-style FFI Stephen J. Turnbull
2013-10-09  2:40                       ` Stefan Monnier
2013-10-12 15:34                         ` Michael Welsh Duggan
2013-10-12 18:55                           ` Stefan Monnier
2013-10-18 13:31                             ` Ted Zlatanov
2013-10-19 14:41                               ` Stefan Monnier
2013-10-19 15:08                               ` Stefan Monnier
2013-10-19 17:33                               ` Andy Moreton
2013-10-19 19:44                                 ` Ted Zlatanov
2013-10-12 23:36                           ` Stephen J. Turnbull [this message]
2013-10-08 19:50                     ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k3higiyz.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=emacs-devel@gnu.org \
    --cc=jerry.james@xemacs.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=mwd@md5i.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).