Upgrade cffi from 1.12.2 to 1.15.0

Source is fetched from
https://foss.heptapod.net/pypy/cffi/-/archive/branch/release-1.15/cffi-branch-release-1.15.zip

Build cffi manually and update Android.bp

Bug: 205265538
Test: None
Change-Id: I91a5ed3b96029b3988602aba6a00c0e0748d0600

1 files changed, 20 insertions, 4 deletions

diff --git a/doc/source/using.rst b/doc/source/using.rst
index ff8e5f1..38c96ba 100644
--- a/doc/source/using.rst
+++ b/doc/source/using.rst
@@ -459,7 +459,7 @@ that you really meant the 42 to be passed as a C ``int``, and not a
 if necessary with ``ffi.cast()``:
 
 .. code-block:: python
-  
+
     lib.printf("hello, %d\n", ffi.cast("int", 42))
     lib.printf("hello, %ld\n", ffi.cast("long", 42))
     lib.printf("hello, %f\n", ffi.cast("double", 42))
@@ -787,7 +787,7 @@ The ``extern "Python"`` functions cannot be variadic for now.  This
 may be implemented in the future.  (`This demo`__ shows how to do it
 anyway, but it is a bit lengthy.)
 
-.. __: https://bitbucket.org/cffi/cffi/src/default/demo/extern_python_varargs.py
+.. __: https://foss.heptapod.net/pypy/cffi/-/blob/branch/default/demo/extern_python_varargs.py
 
 Each corresponding Python callback function is defined with the
 ``@ffi.def_extern()`` decorator.  Be careful when writing this
@@ -876,11 +876,27 @@ ffi.callback() and the result is the same.
       protections can interfere (for example, on SELinux you need to
       run with ``deny_execmem`` set to ``off``).
 
-    Note also that a cffi fix for the latter issue was attempted---see
+    - `On Mac OS X,`__ you need to give your application the entitlement
+      ``com.apple.security.cs.allow-unsigned-executable-memory``.
+
+    Note also that a cffi fix for this issue was attempted---see
     the ``ffi_closure_alloc`` branch---but was not merged because it
     creates potential `memory corruption`__ with ``fork()``.
 
+    In other words: yes, it is dangerous to allow write+execute memory in your
+    program; that's why the various "hardening" options above exist.  But at
+    the same time, these options open wide the door to another attack: if the
+    program forks and then attempts to call any of the ``ffi.callback()``, then
+    this immediately results in a crash---or, with a minimal amount of work
+    from an attacker, arbitrary code execution.  To me it sounds even more
+    dangerous than the original problem, and that's why cffi is not playing
+    along.
+
+    To fix the issue once and for all on the affected platforms, you need
+    to refactor the involved code so that it no longer uses ``ffi.callback()``.
+
 .. __: https://github.com/pyca/pyopenssl/issues/596
+.. __: https://foss.heptapod.net/pypy/cffi/-/issues/391
 .. __: https://bugzilla.redhat.com/show_bug.cgi?id=1249685
 
 Warning: like ffi.new(), ffi.callback() returns a cdata that has
@@ -950,7 +966,7 @@ arguments are passed:
     ffibuilder.compile(verbose=True)
 
 .. code-block:: python
-    
+
     # file "example.py"
 
     from _example import ffi, lib