From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: DSO-style FFI Date: Sun, 13 Oct 2013 08:36:20 +0900 Message-ID: <87k3higiyz.fsf@uwakimon.sk.tsukuba.ac.jp> References: <877gdqrc9u.fsf@flea.lifelogs.com> <87mwmmp05f.fsf@flea.lifelogs.com> <87fvsdpato.fsf@flea.lifelogs.com> <8738oc20xk.fsf@flea.lifelogs.com> <87d2ngzlyl.fsf_-_@flea.lifelogs.com> <87siwcxda7.fsf@flea.lifelogs.com> <87zjqjfz36.fsf@fleche.redhat.com> <87wqlitse5.fsf@maru2.md5i.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1381621008 17071 80.91.229.3 (12 Oct 2013 23:36:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Oct 2013 23:36:48 +0000 (UTC) Cc: Tom Tromey , emacs-devel@gnu.org, Stefan Monnier , jerry.james@xemacs.org To: Michael Welsh Duggan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 13 01:36:51 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VV8jq-0005M8-DI for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2013 01:36:50 +0200 Original-Received: from localhost ([::1]:59672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VV8jp-00011F-Fu for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2013 19:36:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VV8jd-0000mF-94 for emacs-devel@gnu.org; Sat, 12 Oct 2013 19:36:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VV8jV-0006Sj-U8 for emacs-devel@gnu.org; Sat, 12 Oct 2013 19:36:37 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:41615) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VV8jV-0006SB-Cp for emacs-devel@gnu.org; Sat, 12 Oct 2013 19:36:29 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 20AD83FA09E1; Sun, 13 Oct 2013 08:36:21 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 12D3F129E2C; Sun, 13 Oct 2013 08:36:21 +0900 (JST) In-Reply-To: <87wqlitse5.fsf@maru2.md5i.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 182d01410b8d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164166 Archived-At: 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. :-)