[RFC PATCH v3 0/5] Libffi Static Trampolines

[Madhavan T. Venkataraman]

On 1/28/21 8:21 AM, Anthony Green wrote:
> On Wed, Jan 27, 2021 at 2:45 PM Madhavan T. Venkataraman <madvenka@linux.microsoft.com <mailto:madvenka@linux.microsoft.com>> wrote:
> 
>     On 1/27/21 12:00 PM, Anthony Green wrote:
>     > Thanks, Madhaven.   I think I understand now.   Are these statements true?:
>     >
>     > (a) These patches implement trampoline tables, similar to what is implemented in the iOS port.  This hardens the library by eliminating the requirement for writable executable memory.
>     > (b) These patches expose a new public API for hardened trampolines.  (a) uses (b), but doesn't require that (b) be public.
>     > (c) We can release libffi with (a) and not (b).
>     >
>     > Is this correct?  
>     >
> 
>     Yes. This is correct. The public API part is not required.
> 
> 
> In this case, my ask is that you split this into two patches.  The first one, (a), I would like to merge as soon as it seems ready.  
> 

OK. I will remove the public API part, sync with the latest libffi and submit a PR.

> The second one I'm not so sure about yet.  Is it a solution in search of a problem?

The problem currently exists in a lot of applications. However, I have not been able to find
a good example in open source. It is all closed source.

> Is libffi the right place for it?   Should it live in libffi, or be broken out into something that libstatictramp -- that perhaps lives in the libffi repo but doesn't pollute the libffi API?  I don't know yet, but opinions welcome.

I like the idea of a libtramp living in the same repo publishing its own API.

First, let us just focus on (a).

Once that has been merged, I will work on the static trampoline library. I have never done library work
before. So, I will need guidance on library creation, configuration, how to expose an API, how to version it,
etc. I will pester you at that time with my questions. We will cross the bridge when we come to it.

> 
> Also, please use the github PR process for the next round so we can get some automated CI going.  And I prefer reviewing patches within the github UI, tbh.
> 

OK. Will do.

> And again -- I appreciate your effort here.  This is something I've wanted more broadly in libffi ever since Landon Fuller implemented something similar in the iOS port.

Thanks!

Madhavan